ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #07083
Re: Landing team meeting 19.03.14
On Thu, Mar 20, 2014 at 7:34 AM, Paul Larson <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.
pura vida.
--
¡paz y baile!
http://one.ubuntu.com
Follow ups
References