To revert or not to revert

[Tim Gardner]

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.

I am of the opinion that we should revert unverified patches and reflect 
those changes in the changelog as we would normally. In addition Andy 
has suggested that we modify the 'insertchanges' step to detect reverts 
and modify the 'LP: #' string in previous changelog entries such that 
Launchpad does not update the state of the bug upon promotion. Remember 
that a bug state is only updated when a package is promoted to -security 
or -updates.

Does this seem sufficient? I think it has the advantage of documenting 
our thought processes in the changelog without mangling the LP bug 
state. We can then use scripting to expire unverified bugs using normal 
tag groveling.

rtg
-- 
Tim Gardner tim.gardner at canonical.com