On 12/24/2010 12:54 AM, Andrew Flegg wrote:
On Fri, Dec 24, 2010 at 04:59, Arjan van de Ven<[email protected]> wrote:
I was the architect for Red Hat's enterprise QA team for a year, and yes,
MeeGo's QA process is very far from mature compared to what they had. But
doing pointless bureaucracy does not make it better.... far from it. It
makes a lot of wasted manhours on things that add zero value to the actual
quality of the final product. Really.
There's a general tone in the grumbling that "process" is the problem;
not necessarily "_this_ process".
"process" by itself doesn't have to be the problem.
A good process is lightweight and proportional to what you're doing.
Thinking that the world is binary and there are only "bugs" and
"features" is not that.
"Makes MeeGo better" can also be something like "go to a new version of
the upstream package, because it includes all the patches we had".
That's not a bug. That's not a feature. It might even be zero lines of
code change. But it's an improvement for MeeGo since it increases
maintainability. This is just one of the examples of things that are
important, but both don't fit into the current rigid heavy process, and
cause the stupid act of filing dummy bugs.
But for MeeGo to succeed we must be agile and fast innovating. Our
market share on phones and other personal devices is pretty much zero
million, and the competition is out there for some time. Yes quality is
important, but our quality processes must be designed for agile and fast
innovating. If they are not (and I'm not very happy about the whole
quality story around MeeGo to be honest), then either we fail because we
can't innovate fast enough, or we fail because our quality will suck...
or both.
Also, for the MeeGo codebase to be long term viable, we need to roughly
update versions of at least 30% of the packages each release (giving us
basically a 18 months complete refresh time); not doing that will cause
our whole OS to turn into obsolescence and it'll become useless in 2 years.
Right now we're going "I see cows. I see sheep. All mammals thus must be
cows or sheep"; we're reversing the logic and then turning that into
process.
Now to turn this constructive: the Process we follow must be
proportional to the changes that happen.
1) If something is a very small scale change, and can be described
perfectly well in a one line sentence.... writing a good package changelog
entry should be all that is needed. A good changelog is worth a 100
bugzillas ;)
2) If something originates from a bug filed in MeeGo.com filed by a user
(or QA), using that bug number in the changelog is important,
mostly for tracking when the bug got fixed, and for the reporter or
QA to be able to be notified that the developer thinks the bug is fixed
3) Likewise, if something implements an existing feature, the program
office folks will appreciate putting the number in the changelog
2 and 3 are common sense to be honest, and part of writing a good changelog.
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
