This is the mail archive of the
mailing list for the glibc project.
Update on commit and release workflow discussions
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: libc-alpha at sourceware dot org
- Cc: joseph at codesourcery dot org, carlos at redhat dot com, roland at hack dot frob dot com
- Date: Mon, 17 Aug 2015 17:27:48 +0530
- Subject: Update on commit and release workflow discussions
- Authentication-results: sourceware.org; auth=none
Apologies for taking so long to send this. Based on discussions on
the list and then following up on that in the glibc BoF at the
Cauldron, I have made a draft of what our new commit and release
process could look like. I have also attempted to add concrete steps
in places where I felt we only had fuzzy agreement on what the process
should look like. Please chime in with corrections or places where
you think this would trip up.
- One ChangeLog file to rule them all - no more localedata/ChangeLog
or any ChangeLog file other than the top level one.
- Patch submitter: posts patch that has the following:
- A coherent commit title and description
- The ChangeLog entry follows a 'ChangeLog:' field. Figure out
another way to record typos in ChangeLogs, but this should not
block this workflow. (Siddhesh: Most ChangeLog typos I've seen in
the recent years have been incorrect tabs/spaces or similar.
- The email should also have the necessary 'Signed-off-by:' fields
to give credit to all authors contributing to the patch. Figure
out another way to give credit in cases where one may forget to
give credit to the proper authors, but this should not block this
- NEWS entries for notable changes continue to go into the NEWS
file. Bug numbers will be auto-generated, so don't add those.
- Reviewer: reviews the patch and acks it by appending an 'Acked-by: '
to the response.
- Committer: adds the 'Acked-by:' in addition to the Signed-off-by's
and pushes the change, editing the commit description as necessary.
- Uses the --author option to give credit to the author.
- Possibility of adding more annotations such as 'Tested-by:' or
external link references using 'See-also:'
- Post-commit hook:
- Uses the BZ # in the ChangeLog entry to post an update to the
- Updates patchwork patch state
- Release manager:
- Runs a script to generate ChangeLog file and fixes up the
ChangeLog file for any errors
- Script generates bug numbers based on the ChangeLog fields
- Script closes bugs in the bugzilla based on the generated bug list
If this works out, only superceded and unreviewed patches should
remain open on patchwork. If this makes sense, I will start working
on this, using the emacs workflow as the basis. If anyone wants to
help, get in touch with me and we can work a way to split tasks. We
can start using this new method of writing commit logs right away (as
soon as we have consensus, announced by a separate email) but also
maintain the ChangeLog file for now. Once we're comfortable, we ditch
the ChangeLog file (preferrably at 2.23 release) and follow this