On 02/03/2020 14:41, Jonathan Wakely wrote:
On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell 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
On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell 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 o
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 su
On Mon, Mar 02, 2020 at 01:01:46PM +, Richard Earnshaw (lists) wrote:
> 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?)
It's called a "lap", but "criterium" would b
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 t
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 su
On 03/02/2020 18:09, Michael Matz wrote:
But suggesting that using the subject line for tagging is recommended can
lead to subjects like
[PATCH][GCC][Foo][component] Fix foo component bootstrap failure
in an e-mail directed to gcc-patc...@gcc.gnu.org (from somewhen last year,
where Foo/foo wa
On Mon, Feb 03, 2020 at 06:20:20PM +, Michael Matz wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> > Well, I'd review a patch differently depending on whether or not it was
> > already committed, a patch requiring review or an RFC looking for more
> > general comments, so I *do
On Mon, Feb 03, 2020 at 06:54:05PM +0100, Jakub Jelinek wrote:
> On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote:
> > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> >
> > > The idea is that the [...] part is NOT part of the commit, only part of
> > > the email.
> >
> > I unde
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Well, I'd review a patch differently depending on whether or not it was
> already committed, a patch requiring review or an RFC looking for more
> general comments, so I *do* think such an email prefix is useful.
As I said: a very go
Hello,
On Mon, 3 Feb 2020, Jakub Jelinek wrote:
> > > The idea is that the [...] part is NOT part of the commit, only part of
> > > the email.
> >
> > I understand that, but the subject line of this thread says "e-mail
> > subject lines", so I thought we were talking about, well, exactly that;
On Mon, 3 Feb 2020, Michael Matz wrote:
> I understand that, but the subject line of this thread says "e-mail
> subject lines", so I thought we were talking about, well, exactly that;
> and I see no value of these tags in e-mails either.
I agree that [PATCH] is not useful (and in general, anyth
On 03/02/2020 17:48, Michael Matz wrote:
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
The idea is that the [...] part is NOT part of the commit, only part of
the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking
On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
>
> > The idea is that the [...] part is NOT part of the commit, only part of
> > the email.
>
> I understand that, but the subject line of this thread says "e-mail
> subject line
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> The idea is that the [...] part is NOT part of the commit, only part of
> the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking about, well, exactly that;
and I see
On 03/02/2020 17:31, Michael Matz wrote:
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
Where does your '50 chars' limit come from? It's not in the glibc text,
and it's not in the linux kernel text either. AFAICT this is your
invention and you seem to be the only person proposing
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> I think the linux rule (the whole line, not including the parts that are
> removed on commit, should not exceed 75 characters) is far more sensible
> - which is why this draft states this.
FWIW, on a slightly older kerne
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from? It's not in the glibc text,
> and it's not in the linux kernel text either. AFAICT this is your
> invention and you seem to be the only person proposing it.
Nope, it's fairly common, so m
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> On 03/02/2020 13:54, Segher Boessenkool wrote:
> >None of this are *rules*. We should not pretend they are. An email
> >subject should be useful to what the receivers of that email use it for:
> >see if it very interestin
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> On 03/02/2020 13:54, Segher Boessenkool wrote:
> >None of this are *rules*. We should not pretend they are. An email
> >subject should be useful to what the receivers of that email use it for:
> >see if it very interestin
On Mon, 3 Feb 2020 15:04:57 +
"Richard Earnshaw (lists)" wrote:
> On 03/02/2020 14:13, Jonathan Wakely wrote:
> > On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
> >> Where does your '50 chars' limit come from? It's not in the glibc text,
> >> and it's not in the linux kernel
On 03/02/2020 15:13, Richard Earnshaw (lists) wrote:
On 03/02/2020 14:10, Jason Merrill wrote:
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov
wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
Upper case is what glibc has, though it appears that it's a rule
that is
not
strictly
On 03/02/2020 14:10, Jason Merrill wrote:
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
Upper case is what glibc has, though it appears that it's a rule that is
not
strictly followed. If we change it, then it becomes another fr
On 03/02/2020 14:13, Jonathan Wakely wrote:
On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
Where does your '50 chars' limit come from? It's not in the glibc text,
and it's not in the linux kernel text either. AFAICT this is your
invention and you seem to be the only person propos
On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from? It's not in the glibc text,
> and it's not in the linux kernel text either. AFAICT this is your
> invention and you seem to be the only person proposing it.
It's a fairly well established c
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
>
> > Upper case is what glibc has, though it appears that it's a rule that is
> not
> > strictly followed. If we change it, then it becomes another friction
> point
> > between develope
On 03/02/2020 13:54, Segher Boessenkool wrote:
On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
I've not seen any follow-up to this version. Should we go ahead and adopt
this?
Can we please go with 'committed' (lowercase)
On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
>
> > I've not seen any follow-up to this version. Should we go ahead and adopt
> > this?
>
> Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
> S
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Upper case is what glibc has, though it appears that it's a rule that is not
> strictly followed. If we change it, then it becomes another friction point
> between developer groups. Personally, I'd leave it as is, then turn a blind
> eye to s
On 03/02/2020 11:54, Alexander Monakov wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
I've not seen any follow-up to this version. Should we go ahead and adopt
this?
Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
Spelling this with all-caps seems li
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> I've not seen any follow-up to this version. Should we go ahead and adopt
> this?
Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
Spelling this with all-caps seems like a recent thing on gcc-patches, before
every
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
[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
33 matches
Mail list logo
