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

[Colin Watson]

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.

And I do think that in the case of high-profile and complex things like
GNOME, and quite possibly LibreOffice, the right thing to do is to apply
for a documented MRE.  Case-by-case discretion makes more sense for
situations that aren't coming up all the time.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]