Re: micro release exception for LibreOffice
Hi Sebastien, On Mon, Jun 11, 2012 at 12:09:24PM +0200, Sebastien Bacher wrote: Le 05/06/2012 19:29, Bjoern Michaelsen a écrit : We released Precise with the regression in 3.5.3 and people are now waiting for a 3.5.4 SRU/MRE to get the upstream fix. There is some irony hidden in there. Hey TB, Is there any way we could get moving on that issue? The SRU team is not wanting to approve that update without a TB resolution and it has been 10 days the email got sent with one reply from Martin so far, meanwhile the LTS is stucked with a version which has regressions and data lost bugs when we have an update ready which fix those, is there anything else we can do to unblock the situation? The request is for an MRE, and I don't feel that there has been a sufficient history of successful SRUs to allow a blanket MRE for LibreOffice. The upstream requirements and test suite requirements are very nicely met, but without a demonstrable history of successful Ubuntu SRUs, I think it's premature to grant an MRE. -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: GNOME MRE exception
Le 13/06/2012 21:52, Kees Cook a écrit : What sort of test suites are being run when doing Gnome SRUs? Hey Kees, There is no solid testing for most of GNOME (glib has a good coverage, GTK a decent one but otherwise the coverage is pretty poor), they have freeze rules on stable series and we review the diff before uploading though. I do think though it does make sense to trust the desktop team when we think that an update is a reasonable one, we tend to be cautious on what we upload, I still appreciate review from the SRU teams for those uploads in any case. Cheers, Sebastien Bacher -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Giving the SRU team the power to review bugs fixes upstream updates?
On 06/13/2012 03:58 PM, Colin Watson wrote: On Mon, Jun 04, 2012 at 11:58:54AM +0200, Sebastien Bacher wrote: 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. The way I view this is roughly as follows: * Just about every upstream says we should run the most recent version they've released. *In general* this is just not tenable for us; not only do we not have the resources to verify such a high frequency of stable updates, but in a lot of cases they just haven't considered integration costs of whatever non-100%-backward-compatible changes they've made. I wouldn't want us to give up on the notion that it is *generally* sensible to backport patches rather than take new upstream releases; I think that on the whole that's beneficial to the quality of our stable releases. * That said, if an upstream is going to the effort of producing stable release series matching what we're using, I don't think it's worthwhile for us to spend our time doing what amounts to busy-work backporting lots of individual patches. * Such stable release series inevitably include little bits and pieces. I don't think that that should necessarily disqualify them, as long as they pass reasonable judgement by somebody on our side to check for integration booby-traps and the whole update is regression-tested, and I don't think it's a good use of time to do something like filing one SRU bug per commit. * I think that the SRU team has, or should have, discretion to make reasonable judgements on a case-by-case basis about whether it's worthwhile to require backporting vs. an upstream update; just as they have, or should have, a certain amount of leeway regarding what incidental changes they accept in an upload that don't come from upstream (e.g. Maintainer change, autotools updates, translation updates, etc.). * If a package or group of packages is doing this kind of thing a lot, then it will simplify the life of the people uploading those packages to apply for a micro-release exception. That way, you don't have to engage in discussions with SRU team members unfamiliar with your work, the practice is publicly documented, and so on. 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. The policy at the moment says: If all of the changes are appropriate for an SRU by the criteria above, then it is acceptable (and usually easier) to just upload the complete new upstream microrelease instead of backporting the individual patches. Note that some noise introduced by autoreconf is okay, but making structural changes to the build system (such as introducing new library dependencies) is generally not. The second sentence suggests this general notion of having a bit of leeway as long as it's within reasonable bounds, but the first sentence does contradict that a bit. How about we just relax that to If the bulk of the changes are appropriate ...? I want the SRU team to have discretion to do reasonable things, but still avoid setting an expectation that we'll take any random thing blessed by some upstream. +1 And I do think that in the case of high-profile and complex things like GNOME, and quite possibly LibreOffice, the right thing to do is to apply for a documented MRE. Case-by-case discretion makes more sense for situations that aren't coming up all the time. Doing the change Colin proposed above will also make it easier for other packages with similar microrelease practices to go through the normal SRU process a few times before applying for an MRE to the TB. Fixing that chicken and egg problem we currently have where for an MRE to be granted we want to see some experience pushing similar SRUs through but that can't happen until we grant the MRE as the SRU team is rejecting the uploads. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
Re: micro release exception for LibreOffice
Replying to Kees' answer, as I didn't get Sebastien's answer. Kees Cook [2012-06-13 13:13 -0700]: On Wed, Jun 13, 2012 at 10:05:03PM +0200, Sebastien Bacher wrote: - we have regression in precise and some unfixed data loss bugs - we have a SRU ready to address those (new upstream point release) - the SRU team is not wanting to review that update since we don't have SRU rules compliant tracking for every single commit in the update and they suggested to apply for MRE If that is the only reason why it's not accepted, then I think it should be accepted. The SRU team did accept LibO microreleases in the past, but judging case by case, not by a MRE. As I pointed out in my other reply, and Kees seems to agree, it is premature to grant an MRE for LibO given it's (for SRU standards) rather poor SRU history. Bjoern said that future releases should behave better, so let's give it a chance to prove itself. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: GNOME MRE exception
Excerpts from Sebastien Bacher's message of 2012-06-13 13:09:34 -0700: Le 13/06/2012 21:52, Kees Cook a écrit : What sort of test suites are being run when doing Gnome SRUs? Hey Kees, There is no solid testing for most of GNOME (glib has a good coverage, GTK a decent one but otherwise the coverage is pretty poor), they have freeze rules on stable series and we review the diff before uploading though. I do think though it does make sense to trust the desktop team when we think that an update is a reasonable one, we tend to be cautious on what we upload, I still appreciate review from the SRU teams for those uploads in any case. Can we truly consider glib Gnome? I know it comes from the Gnome project, but it has over 3000 reverse dependencies, and some of these are not at all gnome. Things like java, udev, etc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: GNOME MRE exception
On 06/13/2012 02:46 PM, Sebastien Bacher wrote: Le 13/06/2012 21:40, Colin Watson a écrit : I'd be in favour of such an MRE; in fact I was rather surprised to learn that it was believed to be no longer in effect, and I think it's probably ultimately counterproductive for us to have significant barriers in the way of taking GNOME stable releases given their strong history. Thanks Colin, not sure if there was a standing granted exception before but https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions doesn't list it and the SRU team blocked review for those uploads on getting a TB decision. Could I please request that whatever documentation is added for this MRE include what a GNOME package means? Does this mean anything hosted at git.gnome.org? Anything in the desktop seed from git.gnome.org? What about the desktop-extra packages? Something based on the lists here [1] or possibly somewhere else of stuff that's part of the GNOME release? Thanks, MIcah [1] http://git.gnome.org/browse/jhbuild/tree/modulesets -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Hi, On Wed, Jun 13, 2012 at 01:13:56PM -0700, Kees Cook wrote: Currently, it sounds like the SRU process for LO isn't working, and I feel that's a separate problem. I think Colin's suggestions on improving this are probably a good first step. The SRU process is totally missing the realities of LibreOffice on Ubuntu. To implement it as written on time and without missing security disclosure dates I would need a team of ~five just for testing all changes in a 10 Mio LOC GUI application in each minor again and repeating all the upsteam testing again -- this time with launchpad bugs. The current SRU process does not trust upstream testing at all -- which is also ignoring realities. Also note that LibreOffice upstream explicitly synced its release plan to Ubuntu/Fedora release cycles to be able to provide a reasonably stable new LibreOffice major release (3.x.2/3) with the distro release and then be able to provide 3-4 stable minor fix-only updates. It is quite arrogant to assume the LibreOffice decision makers (with lots of experienced ex-OpenOffice veterans by now) dont know what they are doing with their codebase there. Playing it by the (current SRU/MRE) book would make it easy for me: I would never touch LibreOffice once it is released with Ubuntu. Strictly speaking I would even leave the cherry-picking of security-fixes to the security team. Finally, I would have lot of additional air to breath for LibreOffice development. And if there are no reasonable lightwight SRUs/MRE for me, and the quality of 3.x.2/3 is insufficient (and it will be -- esp. compared to other distros of the same age with later minors) the conclusion is simple: going with the last minor of the last major instead. It will not have fewer bugs -- only more bugs which are wellknown. However, given the number of bugfixes in a major, this will give us a huge backslash -- not because of missing features, but because of missing fixes known to be corrected upstream. And I would never need to target a blueprint for the current cycle as whatever I do would only end up in the _next_ cycle.(*) So: For best quality of LibreOffice on Ubuntu with the current resources we need a MRE for LibreOffice. Or a completely different SRU process for LibreOffice. Or lots of additional resources for LibreOffice. Its quite simple actually. Best, Bjoern (*) Dont even try to suggest to regulary do such developments as vendor patches on the old stable branch: a) missing the upstream testing will hurt severely (I am not talking about automated tests, but plain boring manual alpha/beta testing) b) Forwardporting and merging such changes to upstream master around release is nontrivial -- wasting resources we do not have -- and in themselves create regression risks. c) Keeping them vendorpatches is even less of an option. We will quickly and rightfully be cut off upstream QA -- ignoring bugs reported on Ubuntu -- because we ship a different product. That was exactly the situation Ubuntu was facing at both go-oo and Suns OOo. Such things should only be done as rare exceptions -- not as the rule. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Le 13/06/2012 21:46, Kees Cook a écrit : The upstream requirements and test suite requirements are very nicely met, but without a demonstrable history of successful Ubuntu SRUs, I think it's premature to grant an MRE. Hey Kees, So to summarize: - we have regression in precise and some unfixed data loss bugs - we have a SRU ready to address those (new upstream point release) - the SRU team is not wanting to review that update since we don't have SRU rules compliant tracking for every single commit in the update and they suggested to apply for MRE - the TB teem is not wanting to grand a MRE - the libreoffice maintainer position is that libreoffice is too complex to cherry pick the fixes we need in a reasonable timeframe while assuring we don't break thing (he trusts upstream testing of the whole update over what a cherry pick in Ubuntu would provide) What do you suggest as a way out of this situation? Cheers, Sebastien Bacher -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
