ubuntu-phone team mailing list archive

[Bill Filler <bill.filler@xxxxxxxxxxxxx>]

On 03/20/2014 12:30 PM, Leo Arias wrote:
> On Thu, Mar 20, 2014 at 7:34 AM, Paul Larson
> <paul.larson@xxxxxxxxxxxxx <mailto:paul.larson@xxxxxxxxxxxxx>> wrote:
>
>     Do we have a clearly documented "acceptance criteria" for promoting an
>     image? It seems to me that would help avoid some of the  ambiguity in
>     situations like these.
>
>
> The acceptance criteria it's easy. IMO, if a bug affects one of the
> important Ubuntu user experiences, it shouldn't be promoted. Now we
> need to define what's important :)
> The stories from the "Engineering goals & experiences" spreadsheet are
> obviously the most important, any bug that affects one of them should
> be critical and should block new releases on all the involved projects.
> We need to add some old and already implemented user stories that we
> must always check for regressions.
>
> We are working on documenting and automating the user experiences we
> consider more important, but that's going to take time.
>
> I think that something more important at this point and that we are
> missing is a process where we assign a high priority to a bug that has
> a big impact but is not a blocker. If two weeks pass and the bug
> hasn't been fixed, it becomes critical and blocks all the releases of
> the affected projects.
>
> And another really important thing we need to discuss is about the
> kind of issues that are acceptable on the devel image we are
> releasing. We have many dog-fooders that will be affected if things
> break, and some of us are even using the device as our only phone, so
> bugs in there are bad. But when we installed this image we kind-of
> acknowledged that things will be unstable from time to time; and we
> kind-of agreed to be nice about it and collaborate to get things
> fixed. That's what dog-fooding a project in development means.
> So, if trying to keep the image clean is affecting the quality and
> velocity of our projects, we might need to release a version that's
> not perfect. That is the case for qt5.2, even if not all the tests are
> passing, we need to give it to more people so we can collect the bugs
> we haven't been able to discover yet. That will probably be the case
> for the new unity scopes too.
>
> I love that we have such a high bar to release things. But sometimes I
> feel that we forget that we are releasing to a devel image where we
> can introduce unfinished versions with known problems. If we delay the
> release because of the qt5.2 bugs we are investigating, we might not
> have enough time to find new bugs before the final release, and we
> might be delaying other important projects that will also need
> dog-fooding time to be perfect in april.
I completely agree.

We already have the concept of a released image and a proposed image,
yet we block changes from getting into our proposed images quite
frequently which seems wrong because we are so concerned about promoting
it to released. I agree that the released image should be free of
regressions for sure. But perhaps the frequency we are trying to promote
proposed into released is too often, as it's gating our development flow
quite significantly. There are a bunch of very big features in the queue
that can't get in (and hence not get testing) because of this. During a
development cycle we need a way to actually continuously integrate and
the proposed image seems like the place to do this. Maybe we should
consider only promoting "milestone" images to released, where a
milestone defines a set of features/fixes that are targetted and comes
at a fixed cadence (every 2 weeks, once a month, etc).

People who want the cutting edge and can live with regressions would
have a way to install proposed already.

>
> pura vida.
> -- 
> ¡paz y baile!
> http://one.ubuntu.com
>
>