On Thu, Mar 20, 2014 at 1:30 PM, Leo Arias <leo.ar...@canonical.com> wrote: > On Thu, Mar 20, 2014 at 7:34 AM, Paul Larson <paul.lar...@canonical.com> > 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
