To revert or not to revert

[Stefan Bader]

On 11/09/2010 10:31 PM, Andy Whitcroft wrote:
> 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
> 

This looks like a good approach for the changelog and should be relatively
simple to script. Like:

for all lines in changelog up to one starting the version currently in updates
	if there is revert x and x
		change "LP:" to "See"

If I understand Steve correctly, the things he refers to as additional process,
are more related to keep the bug status automatically in sync with the reverts.
So sort of the combined approach sounds to me like:

* Run the scripts that goes through the bug reports and finds unverified ones
* Those get an explanation added, get set to won't fix, have the tags updated
  and get marked for reversion
* If there are things to revert, a new branch is created locally, starting with
  the last proposed upload (this allows master to progress)
* A new version is started and the reverts are done
* Insertchanges will update the LP numbers for reverts
* The new upload is finalized and merged back to master.

Stefan