git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Brian Lyles" <brianmlyles@gmail.com>
Cc: git@vger.kernel.org, phillip.wood123@gmail.com,
	"Jean-Noël AVILA" <jn.avila@free.fr>
Subject: Re: What's cooking in git.git (Mar 2024, #05; Tue, 19)
Date: Thu, 21 Mar 2024 18:59:52 -0700	[thread overview]
Message-ID: <xmqqcyrn58mf.fsf@gitster.g> (raw)
In-Reply-To: <17bef197ac874ae6.70b1dd9aae081c6e.203dcd72f6563036@zivdesk> (Brian Lyles's message of "Fri, 22 Mar 2024 01:22:22 +0000")

"Brian Lyles" <brianmlyles@gmail.com> writes:

> Yes, I suspect you are right. I think the cover letter would be a good
> start at the very least. Would you welcome a patch to
> 'Documentation/SubmittingPatches' that adds a new expectation for this,
> or do you think this would be best handled yourself? I am interested in
> contributing but, as I'm sure you've noticed, I'm also quite new to the
> project =)

I'd prefer to start with a much less official "experimental" launch
of such a new workflow, instead of adding an unproven idea as if it
is a new hard requirement to the SubmittingPatches document.  If it
works well, we can write it down later.

But even a soft launch needs some way to advertise it to the target
audience, and the SubmittingPatches document is the only sensible
place to do so.  So, perhaps do something like this?  I dunno.

------- >8 ------------- >8 ------------- >8 -------
Subject: SubmittingPatches: release-notes entry experiment

It has been the maintainer's task to prepare the description of each
topic listed in the "What's cooking" report.  The description is
automatically picked up from the "What's cooking" report and used in
the commit log message of the merge commit when the topic is merged
into integration branches.  These commit log messges of the merge
commits are then propagated to the release notes.

The original author of a topic may be in the best position to write
the initial description of a topic, but we so far lacked a formal
channel for the author to tell what description to use.  The usual
procedure has been to see the topic described in "What's cooking"
report, and then either complain about inaccurate explanation and/or
offer a rewrite.

Let's try an experiment to optionally let the author propose the one
paragraph description when the topic is submitted.  Pick the cover
letter as the logical place to do so, and describe an experimental
workflow in the SubmittingPatches document.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 [for what's cooking]
 * An experimental procedure for a topic author to propose the topic
   description to be used in "What's cooking" report and in the
   release notes have been added to the SubmittingPatches document.

 Documentation/SubmittingPatches | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git i/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
index e734a3f0f1..05e15b9436 100644
--- i/Documentation/SubmittingPatches
+++ w/Documentation/SubmittingPatches
@@ -459,6 +459,17 @@ an explanation of changes between each iteration can be kept in
 Git-notes and inserted automatically following the three-dash
 line via `git format-patch --notes`.
 
+[[a-paragraph-summary]]
+
+*This is EXPERIMENTAL*.  When sending a topic, you can propose one
+paragraph summary that appears in the "What's cooking" report when it
+is picked up to explain the topic.  If you choose to do so, please
+write 2-5 lines of a paragraph that will fit well in our release notes
+(see Documentation/RelNotes/* directory for examples), and put it in
+the cover letter, clearly marked as such.  For a single-patch series,
+use the space between the three-dash line and the diffstat, as
+described earlier.
+
 [[attachment]]
 Do not attach the patch as a MIME attachment, compressed or not.
 Do not let your e-mail client send quoted-printable.  Do not let


  reply	other threads:[~2024-03-22  2:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19 16:53 What's cooking in git.git (Mar 2024, #05; Tue, 19) Junio C Hamano
2024-03-20 15:15 ` Brian Lyles
2024-03-20 16:11   ` Junio C Hamano
2024-03-21  1:13     ` Brian Lyles
2024-03-21  1:36       ` Junio C Hamano
2024-03-21  2:04         ` Brian Lyles
2024-03-21 13:02       ` Junio C Hamano
2024-03-22  1:22         ` Brian Lyles
2024-03-22  1:59           ` Junio C Hamano [this message]
2024-03-22  2:47             ` Brian Lyles
2024-03-22  5:14               ` Dragan Simic
2024-03-22 12:39                 ` Max Gautier
2024-03-22 13:25                   ` Dragan Simic
2024-03-22 14:46               ` Junio C Hamano
2024-03-22  5:05             ` Dragan Simic

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqcyrn58mf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=brianmlyles@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jn.avila@free.fr \
    --cc=phillip.wood123@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).