From: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
Alexander Monakov <amonakov@ispras.ru>,
Gerald Pfeifer <gerald@pfeifer.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
GCC Development <gcc@gcc.gnu.org>
Subject: Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions
Date: Mon, 03 Feb 2020 15:05:00 -0000 [thread overview]
Message-ID: <a2babc84-d092-b92c-6829-ce586f0eab1d@arm.com> (raw)
In-Reply-To: <CAH6eHdRooSqnZZzk1W28wC2iPSY8jK5Fqb9iEThwsRu5TKxi4A@mail.gmail.com>
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 proposing it.
>
> It's a fairly well established convention, e.g.
> https://chris.beams.io/posts/git-commit/ and it's what Github suggests
> (and whines if you go past it).
>
That suggest it as a limit for everything. If you have a tag and a bug
number then then that would leave very little for the real part of the
summary and would likely lead to something meaningless or
incomprehensible in the remaining characters. That might be OK for
small projects, but for something the size of gcc, I think keeping the
extra flexibility is useful.
>> 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.
>
> I'm OK with that.
>
OK, thanks.
R.
next prev parent reply other threads:[~2020-02-03 15:05 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c3928f40-2d71-fb5b-f2e0-3878ac88a2b7@arm.com>
[not found] ` <alpine.LSU.2.21.2001191425160.739@anthias.pfeifer.com>
[not found] ` <353faf3e-bf43-eb4d-542d-45a53dce77b2@arm.com>
2020-01-21 15:40 ` [PATCH, v2] " Richard Earnshaw (lists)
2020-01-21 16:03 ` Jakub Jelinek
2020-01-21 16:14 ` Richard Earnshaw (lists)
2020-01-21 16:38 ` Jakub Jelinek
2020-01-21 16:43 ` Richard Earnshaw (lists)
2020-01-21 19:27 ` Jason Merrill
2020-01-22 3:46 ` Richard Earnshaw (lists)
2020-01-22 10:00 ` Jakub Jelinek
2020-01-22 13:50 ` Richard Earnshaw (lists)
2020-01-22 13:54 ` Jakub Jelinek
2020-01-22 17:41 ` Richard Sandiford
2020-01-22 17:45 ` Marek Polacek
2020-01-22 17:50 ` Richard Earnshaw (lists)
2020-01-22 9:07 ` Segher Boessenkool
2020-01-22 16:05 ` Richard Earnshaw (lists)
2020-01-22 16:37 ` Segher Boessenkool
2020-01-22 18:49 ` [PATCH, v3] " Richard Earnshaw (lists)
2020-02-03 11:41 ` Richard Earnshaw (lists)
2020-02-03 11:54 ` Alexander Monakov
2020-02-03 11:59 ` Richard Earnshaw (lists)
2020-02-03 12:51 ` Alexander Monakov
2020-02-03 14:11 ` Jason Merrill
2020-02-03 15:13 ` Richard Earnshaw (lists)
2020-02-03 15:15 ` Richard Earnshaw (lists)
2020-02-03 13:54 ` Segher Boessenkool
2020-02-03 14:00 ` Richard Earnshaw (lists)
2020-02-03 14:13 ` Jonathan Wakely
2020-02-03 15:05 ` Richard Earnshaw (lists) [this message]
2020-02-03 16:12 ` Andrew Clayton
2020-02-03 17:17 ` Segher Boessenkool
2020-02-03 17:19 ` Segher Boessenkool
2020-02-03 17:31 ` Michael Matz
2020-02-03 17:36 ` Richard Earnshaw (lists)
2020-02-03 17:49 ` Michael Matz
2020-02-03 17:54 ` Jakub Jelinek
2020-02-03 18:09 ` Michael Matz
2020-02-04 10:41 ` Andrew Stubbs
2020-02-03 18:57 ` Segher Boessenkool
2020-02-03 17:54 ` Richard Earnshaw (lists)
2020-02-03 18:20 ` Michael Matz
2020-02-03 19:48 ` Segher Boessenkool
2020-02-03 18:03 ` Joseph Myers
2020-02-03 17:34 ` Segher Boessenkool
2020-02-27 13:38 ` Nathan Sidwell
2020-03-02 13:01 ` Richard Earnshaw (lists)
2020-03-02 13:35 ` Segher Boessenkool
2020-03-02 14:31 ` Nathan Sidwell
2020-03-02 14:41 ` Jonathan Wakely
2020-03-02 15:22 ` Richard Earnshaw (lists)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2babc84-d092-b92c-6829-ce586f0eab1d@arm.com \
--to=richard.earnshaw@arm.com \
--cc=amonakov@ispras.ru \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=gerald@pfeifer.com \
--cc=jwakely.gcc@gmail.com \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).