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

Sebastien Bacher seb128 at ubuntu.com
Mon Jun 4 09:58:54 UTC 2012


Hi,

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.

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.

Currently our options for those seems to be:

- don't get stable versions SRUed
- backport only the "high profile fixes", which is extra work, miss some 
small fixes, and make us ship an untested code combination rather than 
what upstream is testing and shipping (i.e one of the high profile fixes 
could behave differently without one of the small ones)
- 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)

None of those seems to be optimal solution and quite a step back 
compared to what we used to do until this cycle (i.e review the diff, 
make sure the update has associated bugs, a test plan and seems reasonable).

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?)

Cheers,
Sebastien Bacher



More information about the technical-board mailing list