Towards Meargeable patch submissions for glibc

[Siddhesh Poyarekar]

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