To revert or not to revert

[Andy Whitcroft]

On Tue, Nov 09, 2010 at 03:43:54PM -0500, Steve Conklin wrote:
> On Tue, 2010-11-09 at 14:15 -0500, Tim Gardner wrote:
> > Pursuant to the kernel verification cadence policy recently discussed at 
> > UDS, the question has arisen of how to manage changelogs and whether or 
> > not to revert un-verified patches, or just rebase them out of existence.

When we upload the first version we will have things like:

 linux (1.2.3.4) natty

 * broken things
  - LP: #12345

 -- Andy ....

Here we can get the LP numbers as normal.  If we revert that cause they
don't respond we end up with something like:

 linux (1.2.3.5) natty

 * Revert: "broken things"

 -- Andy ....

 linux (1.2.3.4) natty

 * broken things
  - LP: #12345

 -- Andy ....

Now ... that still looks like the bug is fixed and it also will trigger
bug closure when we move the update to -updates.  However if we simply
adjust the previous entries bug numbers from the original changelog
entry as below (say converting them to http: buglinks might be nice):

 linux (1.2.3.5) natty

 * Revert: "broken things"

 -- Andy ....

 linux (1.2.3.4) natty

 * broken things
  - See #12345

 -- Andy ....

Now the combined upload for -proposed (which will be -v 1.2.3.3 stylee)
will not any longer include the bug numbers.  Also a simple extraction
of the bug numbers will list only the valid patches for the web pages,
and the current automation will also do the right thing when this moves
over to -updates.

I have talked this through with both Pitti and Colin and both were
happy with this approach.

We should not need any other automation?  We could probabally update
fdr insertchanges to look for Revert "foo" and find "foo" and fix the
bug numbers so there may even be no additional process.

-apw