This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Towards Meargeable patch submissions for glibc
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: libc-alpha at sourceware dot org, carlos at redhat dot com, adhemerval dot zanella at linaro dot org, joseph at codesourcery dot com
- Date: Mon, 3 Sep 2018 16:30:42 +0530
- Subject: Towards Meargeable patch submissions for glibc
Hi,
GNU Tools Cauldron 2018 is upon us and it is once again time to discuss
dropping ChangeLogs!
From my memory of previous discussions (and a quick peek at the
archives) it looks like there are points of agreement that we can act
upon and what we need now is someone to volunteer to do it. Here's a
proposal (and a volunteer: me) to discuss and get something started.
Once we have a usable workflow in place and enforced after 2.29 release,
we can auto-generate the ChangeLog file as part of the release process
in 2.30. I can write this script and also manage 2.29/2.30 releases to
help with the transition.
I'll write it all up into a wiki page once we have a high level
agreement on it and then have fist fights in person at Cauldron over the
finer points ;)
/* PROPOSAL */
- Make the ChangeLog entry part of the git commit message with a
specific format. Here's a proposed format:
~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-Off-By: Dev Loper <dev@lo.per>
Signed-Off-By: Pro Grammer <pro@gram.mer>
ChangeLog:
<CL entry without the name and email header>
~~~~~~~~~~~~~~~~~~~~~~~~~~
- Make full review of the patch mandatory, i.e. reviewer checks the git
commit message in addition to the patch and ensures that the commit
message has a clear description of the patch and correct changelog entry
along with the Signed-Off-By for all contributors to the patch.
- Upon positive review, modify the patch commit log to add a
Reviewed-By: line and push the result. There should be _NO_ change to
the content of the patch compared to what was posted; other parts of the
reviewed commit message may change but one must avoid doing so as much
as possible.
- If you push and forget to include the ChangeLog, push an empty commit
immediately with the ChangeLog entry.
/* End PROPOSAL */
We should also do something similar for NEWS entries. We can work that
out during Cauldron since the solution will be similar to this one.
This should get us closer to getting patches that can be merged easily
across branches and automatically using tools. I haven't looked yet,
but maybe we could use patchwork or some other tools to automate some of
the bits after this point since the main blocker for them was the
difference in the final version of the patches.
Siddhesh