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

[Martin Pitt]

Sebastien Bacher [2012-06-04 11:58 +0200]:
> 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.

That's not how I perceived it. As an individual TB member I don't have
the formal power to change Ubuntu policies, only as part of a voting
of the TB.

I usually review the diff of microreleases, read changelogs, the
patches etc., and then accept (or not) the update based on my gut
feeling/experience how regression prone they are, how many bugs it
fixes, whether there are a lot of users subscribed to the fixed LP
bugs, i. e. about the risk/benefit ratio.

I just happened to review most of the GNOME updates because I had
spent the most time on SRU reviewing out of the SRU team members, and
probably also because e. g. Clint rightly prefers the "desktop guys"
to review GNOME related uploads, just as I defer to Dave or Clint to
judge about intrusive server-side SRUs.

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

I reviewed a recent LibO point release, and the changes were not
actually that dramatic. There was an order of 10 bug fixes, and
perhaps some translation updates, not much different from the average
GTK microrelease update. Quite a lot of them also had "real" LP bugs
with lots of users subscribed. It's certainly far away from the scale
of changes that Firefox or new Nova versions introduce.

> - open 15 bugs for SRU tracking, which is tons of work, will
> probably lead to a high number of unverified bugs (who is going to
> verify all those "that's not an issue in practice but we need to
> create a bug for the upstream commit)

This is indeed not a practical solution at all. The point of SRUs is
mostly to fix already existing bug reports, not reports that we
synthetically create -- there are no affected users subscribed to the
latter who could confirm that a fix works, or who we even reach with a
general call for testing. It might make sense to open one or three
"synthetic" bug reports for an upstream update if we can reproduce the
problem easily and consider it important to fix in stable. If not,
then "don't SRU" really does seem like the most adequate option to me.

> I would like to suggest that the TB should give the rights to the
> SRU team to review and accepted updates on those "relaxed" basis,
> what would be the right medium to start this discussion? (this
> email? a meeting agenda? a discussion on one of the project's list?)

It has always been my practice (with my former SRU hat on) to not
treat the SRU policy strictly to the letter, but apply them with the
right amount of common sense to a particular update. We select people
into the SRU team whom we trust to be able to make a decision about
the risk/benefit factor of a particular update, and whether a new
version has a chance of being sufficiently verified. Sometimes SRU
team members require additional testing and feedback on particular
bugs, etc. IMHO the nature of changes introduced in our SRUs, as well
as them being highly dependent on the current circumstances (point in
the release cycle, interactions with particular upstreams, customer
requests, etc.) is way too complex anyway to put it into a concise and
precise policy; I see no way around human interpretation here.

If the current SRU team feels differently about this now, and they
want to be more strict about what they accept, then I suggest to
discuss the consequences of that with the SRU team, preferably with
some actual cases of SRUs that are now being rejected, but should go
in. 

With my TB hat on I had no problem with the previous and more
"relaxed" application of the SRU policy, but I realize that due to my
double role I might have been biased there.

What do the other TB team members think?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)