This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Update on commit and release workflow discussions

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.
    Nothing serious)
  - 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
    relevant BZ
  - 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
workflow full-on.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]