Hash out a solution for ChangeLog/NEWS at the Cauldron?

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

Hi,

I don't know how many of us are going to be at the Cauldron this
weekend, but if there are enough (more than, say, 6), how about coming
up with a patch review and commit policy that doesn't require rebasing
patches?  We're at an almost perfect position with development frozen
(we could keep it frozen for a week till we sort this out so that we
use this policy for all new commits) and people sitting face to face,
which IMO is the best way to solve such non-technical issues.

What I'm thinking of is a policy that'll allow us to auto-generate
ChangeLog and NEWS from commit data so that whatever is posted on the
list can be git-am'd directly and merged into master without rewriting
the commit.  This will allow for tighter integration with patchwork,
to mark committed patches as closed automatically, leaving just
superseded patches to clean up.

One simple solution that comes to my mind is to enforce a structure on
the commit log, which requires all contributors to the patch to be
included with Signed-off-by: tags for each contributor (and maybe
Acked-by too).  The ChangeLog entry can be identified with a
ChangeLog: tag.  Likewise, we could have a NEWS: tag to identify NEWS
items for the release and a BUGS: tag to include bugs that this commit
resolves.

With this in place, the patch committer should take care to never
rebase the patch into master and instead 'merge' it in to preserve
history.  Alternatively, (s)he could ask the submitter to rebase and
provide a patch.

A reviewer could mark a patch as 'Rejected' or 'Changes Requested' by
responding to the patch with Patchwork-Rejected or
Patchwork-changes-requested in its own line at the end of the review.
Likewise for a submitter to Supersede a patch, although they could
alternatively just update state on patchwork.  I don't know if I can
hack up patchwork to identify all these, but I don't mind giving it a
shot if it sounds sane.

Thoughts?

Siddhesh