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
--
technical-board mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/technical-board
