This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions


On 02/03/2020 14:41, Jonathan Wakely wrote:
On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell <nathan@acm.org> wrote:

On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote:
On 27/02/2020 13:37, Nathan Sidwell wrote:
On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote:
On 22/01/2020 17:45, Richard Earnshaw (lists) wrote:

[updated based on v2 discussions]

This patch proposes some new (additional) rules for email subject lines
when contributing to GCC.  The goal is to make sure that, as far as
possible, the subject for a patch will form a good summary when the
message is committed to the repository if applied with 'git am'.  Where
possible, I've tried to align these rules with those already in
use for glibc, so that the differences are minimal and only where
necessary.

Some things that differ from existing practice (at least by some
people)
are:

- Use '<topic>:' rather than '[<topic>]'
    - This is more git friendly and works with 'git am'.
- Put bug numbers at the end of the line rather than the beginning.
    - The bug number is useful, but not as useful as the brief summary.
      Also, use the shortened form, as the topic part is more usefully
      conveyed in the proper topic field (see above).

I've not seen any follow-up to this version.  Should we go ahead and
adopt this?

I'd like to.  But have we reached consensus?  Seems that every time I
produce a revised version of the text we end up in another round of bike
shedding.  (Is that a word?)

I'm not sure I've seen a specific proposal following yours.  Some
suggestions for differences, with varying degrees of forcefulness.  I
still say go for it.

Go for it.

It's not like we're going to take away commit privs from people who
use slight variations on the scheme. It's better to have a written
policy that people should aim towards, and most people will follow in
most cases.


OK, pushed. Folk can, of course, now propose changes to the text as it stands...

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]