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

Wed Jun 13 20:13:25 UTC 2012

On 06/13/2012 03:58 PM, Colin Watson wrote:
> 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.

+1

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

Doing the change Colin proposed above will also make it easier for other
packages with similar microrelease practices to go through the normal
SRU process a few times before applying for an MRE to the TB.

Fixing that chicken and egg problem we currently have where for an MRE
to be granted we want to see some experience pushing similar SRUs
through but that can't happen until we grant the MRE as the SRU team is
rejecting the uploads.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20120613/2161dec4/attachment.pgp>