Ubuntu Touch release mechanics

[Scott Kitterman]

On Friday, September 20, 2013 00:57:02 Steve Langasek wrote:
> Hi Scott,
> 
> On Thu, Sep 19, 2013 at 10:34:33PM -0400, Scott Kitterman wrote:
> > On Thursday, September 19, 2013 18:30:17 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.
> > 
> > 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.
> 
> I don't know if you're suggesting the qtwebkit-opensource-src package
> landing was contrary to protocol (in violation of the feature freeze?); you
> say "without a lot of discussion", but that's not the same thing as no
> discussion, and this seems to have been explicitly approved by Jonathan as
> an FFe in bug #1219695.  So I'm not sure what the concern is there.  I don't
> think it's being suggested that the Touch team would "control" these
> packages in the sense of being allowed to make changes to them that don't
> fall under the existing FFes, only that they would have a sensible
> mechanism for controlling how and when changes that *are* covered by FFes
> land in the release pocket.

The FFe was for updating all of Qt5 to 5.1.1.  It seemed to me that it only 
ever got mentioned in the bug that the plan had changed because I asked for 
status.  I don't think that there was any kind of formal process violation 
here because, as you say, there was an FFe, but I also think that the 
communication about what was going on could have been more verbose.

> > 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.
> 
> The reason it wasn't announced is that it was understood both that Ubuntu
> developers outside of Canonical aren't answerable to Canonical management,
> and that the risk originates entirely within the Canonical team due to
> ongoing feature development targeting 13.10 for Ubuntu Touch.  Although
> Colin didn't say so explicitly, I think the logical extension of this is
> that community members are *not* required to coordinate their changes with
> the folks managing the Ubuntu Touch landing, regardless of which mechanism
> is used for coordination within Canonical.
> 
> So in the context of the spreadsheet, it was entirely appropriate to ask for
> the folks within Canonical who were working on the Qt 5.1 landing to
> coordinate that with respect to other changes landing on the phone images;
> but that doesn't imply either that the team has been given carte blanche to
> make *other* changes to qtwebkit, or that community changes are expected to
> pass a gauntlet with the Touch team before they can be accepted into the
> archive.

I have seen grumpiness (it was awhile ago, I don't recall specifics) when other 
packages that are normally run through the CI infrastructure get uploaded 
straight to the archive, so I am (perhaps overly) concerned about a trend 
towards there being mechanisms in place that it's difficult for the broader 
community to participate in.

I agree it wouldn't have been appropriate to try and enforce the landing plan 
outside Canonical (as you suggest), but at the same time, I think being more 
verbose about the planning (as above) is helpful.

I don't think the touch team has been given carte blanche over qtwebkit.  If 
they have, we need to re-assess that for next cycle because that's not a touch 
specific package.

Scott K