ubuntu-phone team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Thu, Mar 20, 2014 at 1:30 PM, Leo Arias <leo.arias@xxxxxxxxxxxxx> wrote:
> 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 :)

In any case; sometimes common sense is enough; anyone who listens to
music on any device that can output sound would be affected by this
particular case.

I +1 since one the upstream authors also thinks it's not in a good state.

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

Is this public and tracked against?

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

My opinion is, and it's a stretch, is that you are allowed to break
devel-proposed and it's one of the reasons everyone wanted clicks
since they lived outside of image builds available to the public.
General users tracking devel-proposed are in it at their own stake.

That said; it doesn't mean it has to be in a broken state all the
time, balance is hard.