Ubuntu Touch release mechanics

[Scott Kitterman]

On Thursday, September 19, 2013 18:30:17 Colin Watson wrote:
> Hi folks,
> 
> 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.

I happened to have recently run across a discussion about this spreadsheet, so 
I am, merely by coincidence, aware of it.  While almost all of the packages on 
their list are on the phone image, some of them are not limited to the phone, 
in particular qtwebkit 5.1.1 that was just landed without a lot of discussion 
outside their team.  I don't think such general packages should be on a list 
of packages that Touch "controls".  qtwebkit-opensource-src is in both the 
Ubuntu Desktop and Kubuntu packagesets.

This completely unannounced list of packages they don't want people to touch, 
doesn't help much if it's not announced.  This needs to go to U-D-A, but it 
does need (as you did put it) to be in form a request.  We don't have 
maintainer locks on packages in Ubuntu and that's an organizational feature we 
should maintain.

> 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.

Several of the people in the team are not ubuntu-dev.  I don't think we should 
be handing out britney access to non-developers.  I think the subset of the 
team that are Ubuntu Developers would be fine (and there's at least one non-dev 
on the team that could, I'm sure, trivially get it back if he asked the DMB).

> 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 think as long as access is limited to Ubuntu Developers and they only manage 
packages that are unique to their images/package sets it's a reasonable thing 
to do (a quick scan of the packages on the spreadsheet suggests to me that 
qtwebkit-opensource-src is the only package that affects (and it's been 
landed).

For the future, I'd suggest these teams be limited to core-dev or MOTU/flavor 
dev with some demonstrated understanding of archive wide management issues.  
All the Ubuntu Dev on the currently proposed team are core-dev, so that 
distinction isn't relevant to the current experiment.

Scott K