ubuntu-phone team mailing list archive

[Scott Kitterman <ubuntu@xxxxxxxxxxxxx>]

On Thursday, March 20, 2014 20:30:42 Adam Conrad wrote:
> On Thu, Mar 20, 2014 at 10:23:44PM -0400, Scott Kitterman wrote:
> > On Thursday, March 20, 2014 18:58:28 Alexander Sack wrote:
> > > The bugs that are needed to get fixed are below:
> > >  * music-app: https://bugs.launchpad.net/music-app/+bug/1292306 (Kevin
> > > 
> > > and Saviq)
> > > 
> > >  *  alarms:
> > > https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/129512
> > > 2
> > > (Thomas S.)
> > > 
> > >  * alarms:
> > > https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/129523
> > > 7
> > > (Thomas S.)
> > 
> > If you want to make changes in current policy for archive uploads, I think
> > that should be coordinated with ubuntu-release.  "But it's phone ..."
> > doesn't give free reign to bypass the community structure of Ubuntu.
> 
> I might also point out that this is completely backwards.  I think we
> would absolutely understand (and the community might not only play
> along but even help out) if this was a case of "We're seeing a ton of
> massive crashes throughout the phone and we can't track it down, can
> you please not churn the bases sytem for a bit while we hunt."
> 
> This isn't that.  These are leaf packages.  It's not remotely scalable
> in a massive distributed project to ask everyone else to not upload
> glibc, dbus, bash, upstart, etc (all things that are on phone images),
> because of some bugs in some leaf packages.
> 
> Lots of leaf packages have bugs.  If we "stopped the line" for every
> package with a bug, we'd get exactly nothing done.  Stopping the line
> for the engineers who work on those packages is fine, and refocussing
> their efforts on fixing the bugs is even more fine.  Asking everyone
> else to twiddle their thumbs while that happens isn't.
> 
> This timing is extra unpleasant, as we (the release team) are about to
> freeze the world for the beta on Monday.  Asking people not to upload
> between now and then is denying them four days to get their pre-beta
> fixes in, none of which would affect the current state of the above
> three apps.
> 
> ... Adam

This is a good point.  One of the big problems in this cycle was the late 
landing of Qt5.  As we discussed in the vUDS session, one reason for it coming 
late was the view that we had to have zero regressions before we could stay 
out of the archive.  In this cycle we survived it because Qt5 only had one 
major user, but that won't be the case next cycle.

In a large integrated project like this it just doesn't scale to stop 
development every time there's a bump in the road.  There will be bumps.  QA 
stuff is great to minimize them, but they're going to happen.  The only way to 
not introduce new issues is to never introduce anything new.

Scott K