To revert or not to revert

[Steve Conklin]

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.
> 
> 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

Yes - but. We have additional needs due to the new process.

Our new process requires that we identify bugs in launchpad which are
associated with a -proposed release, so that we can track and enforce
the verification requirement. The only way we really have to do that is
to extract those bug numbers from the changelog in the uploaded package,
as is done for the status changes when a package hits -security or
-updates. It's naive to think that we'll never have a set of patches go
back to the beginning of a proposed cycle once we've reverted patches -
this could happen due to some security release timings, or failures in
regression and certification testing. So we'll need to be sure that we
can also exclude bugs for which the patches have been reverted from
processing of a kernel that's in proposed.

There are a few ways to solve this - one of the simplest is just to add
a new bug tag. Something like "stable-revert". I'd rather make it
separate from the verification-[needed|done] set, as these get
manipulated by archive admin scripts. 

We also need a way to flag bugs which are meta-bugs used as part of
various processes. These are bugs like the SRU upstream stable release
tracking bugs - they are (as far as I know) only set to verified
manually by the archive admin, and we don't even want to try to parse
them for commits to revert. How about "stable-meta-norevert"?

If this is OK, we can start writing the scripting for handling this in
Launchpad. The work flow will look like this:

(processing at end of verification window)
Extract all bug numbers from the uploaded packages changelog.
For each of those bugs:
  if it has the "stable-meta-norevert" tag, skip it
  if it has "verification-failed" tag, set off alarms
        and handle as not verified.
  if it does not have "verification-done" tag:
     add text explaining why we're reverting it
     add the tag "stable-revert"
     ???? remove verification-needed tag if present
     add it to a list of bugs to have patches reverted
        (if possible, map back to commit IDs at this step)
  Send email to ubuntu-kernelteam with results

This does let us handle the cases I can think of without changing bug
state, and by only adding tags. I'm concerned about tag proliferation,
but I've attempted to start defining a tag namespace by preceding ours
with "stable-".

What do you think?

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20101109/8d624797/attachment.sig>