Re: Per-pocket upload permissions
On 06/14/2012 07:24 AM, Colin Watson wrote: Hi folks, My fix to https://bugs.launchpad.net/launchpad/+bug/914779 (second time lucky) will hopefully be rolled out tomorrow, or failing that on Monday. Once that's in place, I would like to add the following upload permissions as suggested by Iain Lane: -backports: ~ubuntu-backporters -security: ~ubuntu-security Iain also suggested -proposed/-updates: ~ubuntu-sru, but I don't think that makes so much sense; ~ubuntu-sru has more of a queue admin kind of role, so I'd prefer that to wait until I get round to a bit of follow-up work to allow per-pocket queue admins. Please note that this does not affect the policy on what goes into the unapproved queue. For example, uploads to stable-backports always require approval by somebody with appropriate queue admin privileges. The difference this will make is that, for example, members of ~ubuntu-backporters who aren't in ~ubuntu-core-dev will be able to upload backports of packages in main without having them outright rejected by Launchpad before they even get to manual queue processing. I believe that we agreed a UDS or two ago that it would be fine to allow ~ubuntu-backporters blanket upload access to their pocket once the software was ready for it, and now it is. Thanks, Sounds perfectly reasonable to me and matches what I remember from the discussions we had at the past few UDS. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: GNOME MRE exception
Hello Sebastien, Sebastien Bacher [2012-06-05 16:02 +0200]: The SRU team suggested that the desktop team should apply for a SRU MRE for GNOME to ease SRU work for precise (and other series) so there we go. GNOME used to have a standard feature freeze exception in Ubuntu and got granted MRE for lucid. Their schedule is reliable and they have ui, string and feature freezes on stable series. Kees pointed out some troubles with hardy GNOME SRUs. I do not actually remember those, perhaps Kees can point to an example? Anyway, almost all GNOME point release packages were quite decent and worthwhile to have, so in general I am in favor of this based on a good multi-year track record. The one exception that comes to my mind is the fairly recent glib change that deprecated something in gsettings. However, this was not actually policy fail, just process fail: the developer did not actually mean to commit this for the stable release and just assumed master would already be for the next major development series. So in sum, I agree to you that desktop and SRU team members should still review NEWS very carefully, and checking that the (filtered) diff looks reasonable. But that is true for all other MREs as well, so I don't consider that a special case. So +1 from me as well. We have three +1 now and an yet undecided from Kees; Soren, Stephane, any opinion? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Per-pocket upload permissions
On Thursday, June 14, 2012 12:37:46 PM Iain Lane wrote: Hi there, On Thu, Jun 14, 2012 at 12:24:07PM +0100, Colin Watson wrote: Hi folks, My fix to https://bugs.launchpad.net/launchpad/+bug/914779 (second time lucky) will hopefully be rolled out tomorrow, or failing that on Monday. Once that's in place, I would like to add the following upload permissions as suggested by Iain Lane: -backports: ~ubuntu-backporters -security: ~ubuntu-security Iain also suggested -proposed/-updates: ~ubuntu-sru, but I don't think that makes so much sense; ~ubuntu-sru has more of a queue admin kind of role, so I'd prefer that to wait until I get round to a bit of follow-up work to allow per-pocket queue admins. Thanks for the work — this is a nice improvement. :-) On this point, I can't be entirely sure (it was some time ago), but I suppose I was thinking that it would be good to ensure that SRU team members can use sru-release themselves, which requires upload privileges due to the use of copyPackage via the API if I'm not mistaken (only -updates would be needed here, not -proposed. -proposed is probably not so useful, except if we want to ensure that they can sponsor all SRUs too). If there's also another UNAPPROVED step there then just being able to upload doesn't gain much: queue admin would also be required. Not that I get a vote, but I'm glad to see this landing. I do think the ~ubuntu-sru ought to be able to accept to -proposed and copy to -updates for current/supported releases. This would remove the need to make ~ubuntu-sru members part of ~ubuntu-archive solely for the purpose of performing SRU processing. I'm 100% agnostic on implementation. Similarly (and I swear we've discussed this before and it's an an LP bug, but I can't find it) I think ~ubuntu-release ought to be able to accept to -release and -proposed, but only for the development release. Similarly, that would remove the need for ~ubuntu-release members to be added to ~ubuntu-archive to process the queue during freezes. My agnosticism about implementation applies to this as well. Scott K -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: micro release exception for LibreOffice
Bjoern Michaelsen [2012-06-13 23:57 +0200]: 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. That's indeed what it comes down to: Either the changes to the microreleases are confined to regression proof bug fixes only (which are SRUable without an MRE even), then we should upload them to stable Ubuntus. Or they continue to introduce regressions (as they repeatedly did in the past), we just don't do them and cherrypick security fixes only. I fully agree to you that it makes no sense to try and pick apart the changes from upstream in most cases, if we don't even have a Launchpad bug report about them. Based on some mails you sent me it seems to me that microreleases of current LibO series should be a lot better than in the past, so I hope that we can upload them. 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: Micro Release Exception request for ubuntuone package set
Hi Martin, Sorry for the slow reply. It's been an extremely busy couple of weeks, with trying to get some U1 releases done, and the set of security updates sneaking up in the middle of that. Ditën e Tue, 05/06/2012 më 17.25 +0200, Martin Pitt ka shkruar: Hello Rodney, Rodney Dawes [2012-05-30 14:54 -0400]: I would like to request a Micro Release Exception for the ubuntuone package set in Ubuntu, so that we may more efficiently release SRUs to users. A more recent new microrelease in -proposed [1] was in line with thet normal SRU policy, and all the bugs there got properly verified. So my main question is, what is the reason why you ask for an MRE? Usually there is two reasons: * You want to do a large number of bug fixes which already get regression tested through a process other than the current call for testing during an SRU. Prime examples here are landscape-client and nova. We want this. We will generally have several bug fixes per package, across several of our packages, which we will update. We also want to have version consistency across all our packages, so that it is easier for support to deal with. * You want to introduce changes in those microreleases which are are not covered by the usual SRU policy, like new features or UI changes. Prime example here is Firefox. We won't be doing this (at least, not yet anyway). When we have new versions of all our packages working reliably in our PPAs, on all the versions of Ubuntu which we want to support with that new version, then we will likely revisit how to do this exactly. And I'm sure there will be further discussion on the best way to do that in Ubuntu. But for now, it's just normal frozen updates with bug fixes. In the first case you should point out how you can verify the actual .debs in -proposed, in a full Ubuntu environment (as that can/will look differently than sandboxes during package build, and packages in PPAs). In the second case you'd keep the individual bug verification, but should justify why UI/feature changes are necessary. We have our own QA resources on Ubuntu One, and have them install all the -proposed packages in a full Ubuntu in a VM to test. We generally do this anyway, as waiting for original reporters to verify fixes may never happen. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
