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