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

[Scott Kitterman]

Sebastien Bacher <seb128 at ubuntu.com> wrote:

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

Option 4 would be to review upstream's update policy and if it's generally consistent with SRU policy plus minor fixes (i. e. no new features) then ask the Tech Board for a microversion release exception.

This is what I thought the current policy was and I think it makes sense.

Scott K