Ubuntu Touch release mechanics

Steve Langasek steve.langasek at ubuntu.com
Fri Sep 20 05:59:49 UTC 2013


Hi Colin,

On Thu, Sep 19, 2013 at 06:30:17PM +0100, Colin Watson wrote:
> I've been working with the Ubuntu Touch folks to try to improve how
> they're landing changes.  At the moment, to try to keep control of
> things in the run-up to 13.10, they're tracking all their landings in a
> spreadsheet and asking people not to upload things out-of-band from that
> that affect Touch images.  A few of us saw some improvements to be made
> here and suggested using proposed-migration blocks instead of gatewaying
> uploads, in the hope that that will involve less many-to-many
> communication and make it easier to test and approve changes.

> So, I've set up an ~ubuntu-touch-release team with a list of members
> given by Alexander Sack, and I plan to give them a hints bzr branch
> shortly with the delegated ability to use the "block" and "unblock"
> hints.  At the moment we have no way to access-control this to just
> certain images, but TBH I trust that those people are way too busy at
> the moment to want to spend time interfering with anyone else. :-)  If
> it becomes a problem then I can certainly look into that.

> I realise I didn't discuss this very far in advance (though I haven't
> actually set up the delegation yet), which is because it's been
> happening too quickly - sorry about that.  But I think this level of
> control is a reasonable one to delegate to people release-managing an
> image and shouldn't cause a problem if we talk to each other.  For most
> of the time between now and 13.10 a lot of the archive is going to be
> blocked anyway, and I expect we'll want to look at how this worked after
> 13.10.

> For the avoidance of doubt, if people think this experiment is a
> reasonable one, I think it would make sense to extend it to more of the
> image release management teams in perhaps a slightly less ad-hoc way;
> perhaps each image release management team should be able to
> block/unblock uploads within their package set, for instance, so that it
> doesn't all have to be within the primary release team who have full
> control and can break anything.  What would people think of that kind of
> thing?

I'm in favor of having something more regular in this regard across the
teams for each image, yes, and also agree with Scott's stipulation that the
people at the controls should be in ubuntu-dev.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20130920/ce8860f1/attachment.pgp>


More information about the Ubuntu-release mailing list