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