On 24/12/10 04:59, Arjan van de Ven wrote:
Doing pointless paperwork does not a rigorous QA process make.
Good - so this thread is asking what the point of this tracking is?
I am trying to use a more constructive 'tone' - just FYI,
I was the architect for Red Hat's enterprise QA team for a year,
Another good - I was an architect in BT for 9 years so I know where you're
coming from. One thing I'm sure you'll realise is that being an architect in a
larger organisation is sadly overrated and involves far more paperwork and
organisational skills than our techy hearts would prefer ;)
IMHO one of an architects clear responsibilities is to manage the bureaucratic
ogranisational overhead and shield his technical team from it; not as much fun
as hacking on code but...
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.
I quite agree. I have seen too much "pointless" bureaucracy. Now... about those
constructive suggestions you snipped :
So it seems to me that a responsible thing to do is not just "drop the process"
but to try and understand the objectives and ensure we're fixing the process,
not just dropping it at the first speed bump.
In particular who has the authority to say "oaktrail is supported in MeeGo"? How
on earth did kai end up working on a kernel adaptation? In all of that did
no-one have the time to create an FEA? Frankly Arjan ... should _you_ have
created that FEA? If not then maybe you should just empower yourself and JFDI in
future?
Frankly I think MeeGo should be much more hard-nosed in keeping things *out* of
core/UX areas and push things into the community area where there are *much*
fuzzier edges.
On 24/12/10 04:57, Arjan van de Ven wrote:
On 12/23/2010 4:25 PM, David Greaves wrote:
Is it reasonable to say that:
"In principle every change should be fixing a bug or contributing to a
feature"
every change should be improving MeeGo. While that translate to fixing a
bug or adding an enhancement,
Good - we have some common ground.
Really - what are we trying to achieve in this process? Both at a high level
('quality') and a lower level (daily communication to the QA team about the bugs
and features touched in a daily snapshot)
For MeeGo to have a chance of success, the amount of "paperwork" must at
the very minimum be in proportion to the change you are making..
Good principle. I made a suggestion about how FEA can be re-used more in another
mail.
Right
now this is waaaaaay off
So the paperwork is too hard? Do we need a simpler 'entry-only' for BZ that lets
us record this stuff more readily?
and this is turning away contributors. (I see
this internally with people who want to contribute some small thing..
and then get their improvement rejected.. they go "WTF" and go back to
working on some other distro instead).
As I write I see a great reply from Andrew on this subject.
So... can we focus on identifying what we need to achieve and how we best do it.
I would far rather spend time trying to construct a viable process that suits
our needs than argue about what's wrong with what we have (which "in the real
world" would also risks someone coming in with an axe and enforcing a process
that doesn't suit us!)
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
