Giving the SRU team the power to review bugs fixes upstream updates?

[Clint Byrum]

Excerpts from Colin Watson's message of 2012-06-13 12:58:14 -0700:
> On Mon, Jun 04, 2012 at 11:58:54AM +0200, Sebastien Bacher wrote:
> > The SRU team started recently being stricter about what they accept,
> > one side effect is that upstream "stable bugsfixes updates" are not
> > welcome anymore if every single commit or change in the diff doesn't
> > follow the SRU rules (i.e having a bug with documented rational,
> > test case, etc).
> > 
> > I've been talking to Steve Langasek about that and he said those
> > happened to be ok before just because Martin by its TB membership
> > had the power to accept those but the non-TB members of the SRU team
> > can't because the TB didn't grant the SRU team the rights to take
> > those decisions.
> > 
> > In practice it means that updates like libreoffice 3.5.3 to 3.5.4
> > have no chance to go in as a stable update under the current rules,
> > we got issues recently for GNOME as well. While those could be
> > addressed through MRE, Bjoern sent one for libreoffice, I think it's
> > an issue for Ubuntu that we can't get a bugfix update reaching
> > stable users without that.
> 
> The way I view this is roughly as follows:
> 
>  * Just about every upstream says we should run the most recent version
>    they've released.  *In general* this is just not tenable for us; not
>    only do we not have the resources to verify such a high frequency of
>    stable updates, but in a lot of cases they just haven't considered
>    integration costs of whatever non-100%-backward-compatible changes
>    they've made.  I wouldn't want us to give up on the notion that it is
>    *generally* sensible to backport patches rather than take new
>    upstream releases; I think that on the whole that's beneficial to the
>    quality of our stable releases.
> 
>  * That said, if an upstream is going to the effort of producing stable
>    release series matching what we're using, I don't think it's
>    worthwhile for us to spend our time doing what amounts to busy-work
>    backporting lots of individual patches.
> 
>  * Such stable release series inevitably include little bits and pieces.
>    I don't think that that should necessarily disqualify them, as long
>    as they pass reasonable judgement by somebody on our side to check
>    for integration booby-traps and the whole update is
>    regression-tested, and I don't think it's a good use of time to do
>    something like filing one SRU bug per commit.
> 
>  * I think that the SRU team has, or should have, discretion to make
>    reasonable judgements on a case-by-case basis about whether it's
>    worthwhile to require backporting vs. an upstream update; just as
>    they have, or should have, a certain amount of leeway regarding what
>    incidental changes they accept in an upload that don't come from
>    upstream (e.g. Maintainer change, autotools updates, translation
>    updates, etc.).
> 
>  * If a package or group of packages is doing this kind of thing a lot,
>    then it will simplify the life of the people uploading those packages
>    to apply for a micro-release exception.  That way, you don't have to
>    engage in discussions with SRU team members unfamiliar with your
>    work, the practice is publicly documented, and so on.
> 
> > Lot of upstreams do have stable series where a typical update is
> > around 15 commits including translation updates, small fixes and
> > some higher profile fixes that would qualify under our SRU rules.
> 
> The policy at the moment says:
> 
>   "If all of the changes are appropriate for an SRU by the criteria
>   above, then it is acceptable (and usually easier) to just upload the
>   complete new upstream microrelease instead of backporting the
>   individual patches.  Note that some noise introduced by autoreconf is
>   okay, but making structural changes to the build system (such as
>   introducing new library dependencies) is generally not."
> 
> The second sentence suggests this general notion of having a bit of
> leeway as long as it's within reasonable bounds, but the first sentence
> does contradict that a bit.  How about we just relax that to "If the
> bulk of the changes are appropriate ..."?  I want the SRU team to have
> discretion to do reasonable things, but still avoid setting an
> expectation that we'll take any random thing blessed by some upstream.

This is all extremely helpful, thank you Colin.

My reservation about this, as an SRU team member, is that it is not
always clear what is a change that will have potential side effects,
and what isn't.

Perhaps I am being over zealous, but I read each and every line of each
diff submitted for SRU. I certainly understand how to filter out known
auto-generated files, and I can usually figure out how to filter out
the translation updates, documentation changes, etc.

But after that, there are often many thousands of lines of change that
must be considered.

Even getting to that point is extremely time consuming and a bit error
prone as it must be done differently package-by-package.

I want the process to be more streamlined as well, but I don't know if
just giving us more discretion is going to do that. I would predict that
it will have one of two effects. Either we will be slowed down because
instead of rejecting things that are too big, we will now be expected
to review them in full, *OR* we will get sloppy and start filtering too
aggressively, and regression frequency will increase.

I think methods which shift the burden from the SRU team to the general
Ubuntu Developer community will have more of a net-positive effect on
the SRU process. Two of these methods right now are cherry picking,
and the MRE process.

Perhaps there needs to be something in between those, where we can
have an SRU which is submitted with extra supporting documentation of
regression testing and planning for regression testing, so that we can
feel comfortable accepting things without having reviewed the code so
completely.