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 :) 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
-- 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
