Hi Thorsten,
Thanks for your mail - this is good stuff.
On Tue, 2006-10-31 at 10:45 +0100, Thorsten Ziehm wrote:
> Yes the specification process was introduced in OOo 2.0 time frame.
> But it doesn't work, as you said. The bug count was high in OOo 2.0.
> Therefore a template for specifications were developed to eliminate
> the most important faults.
Sure - I just don't think that (given the mixed results of the initial
spec. process to substantially improve quality) it's possible to
authoritatively state that increases in code quality post 2.0.0 are due
to the [new] spec. process itself. So much changed (for the better),
it's hard to say where the dominant effects are.
> >> I think this is one reason why OpenOffice.org is so successful.
> > Do you have data to back that up ?
>
> It isn't possible to get data here. But from my own feeling and
> discussion with many people, quality is the highest priority.
Of course, anecdotally I have a different slant :-) to measure this -
if we do user surveys we could perhaps work out some questions to ask
that would measure this (though it's hard to phrase them I suppose):
"What did you notice most about OO.o 2.0
a) better interop
b) new Impress layout
c) improved stability
..."
it'd be interesting to see the result. [ I thought Sun did market
research of this form, perhaps Erwin has some hard data ].
> > "OO.o is incredibly slow to start"
>
> Yes this is a bug. But I think it is more than one bug.
:-) indeed.
> Unit tests and tests with automated TestTool are different level of
> quality assurance in Software. Unit tests are used to check the code
> itself. The next level are API tests to check the integrated code
> in the whole content.
Sure - of course, being able to run large numbers of very complex tests
very quickly inside a local developer's build tree is clearly a good
goal, and (I hope) quite attainable.
> > So - I need a deeper understanding of what you understand
>> by quality and how you weight these statements:
This was very interesting indeed, and broadly I agree with you, so
perhaps we're not so far apart at all :-)
> User perspective :
> In my opinion we had the following goals in the last updates.
> (I changed the order of your points)
>
> > + Quality is OO.o not crashing (stability)
> > + Quality is OO.o not loosing data
> > + Quality is OO.o loading & saving my 'foreign' data files
> > + Quality is OO.o performing acceptably
> > + Quality is OO.o not consuming all available memory
And we don't do too badly with the above.
> > + Quality is OO.o behaving ergonomically as I expect
> > + Quality is OO.o being slick & beautiful
> > + Quality is OO.o being feature competitive with others
I guess these last 3 are what the spec. process targets, and of course
prolly where we need the most extra polish all over the place.
Unfortunately wrt. slickness the large number of small changes to make
OO.o 'slick' [ a vague term it's true ], are substantially retarded by
the spec. process - which concerns me.
> Code contributor perspective :
> These are important points too. These are and should be goals for
> the development. I cannot speak about that, because I am not
> the professional in code quality.
>
> > + Quality is OO.o source code being readable
> > + Quality is OO.o source code being maintainable
> > + Quality is OO.o source code being consistent
> > + Quality is OO.o source code not being cut/pasted
So - here we can perhaps use automated lint style tools to help [ eg.
the warnings redux work is really useful here I think ], we could also
(perhaps) use one or other of the cut/paste detection tools to generate
a metric before/afterwards and point out the delta. The other bits can
only be improved by code review I think.
> The quality (user and developer perspective) can be increased with
> specifications. But specifications are not a part of the quality.
>
> > + Quality is every aspect of OO.o having a detailed spec.
And this is the wonderful. It's great that you view the spec. process
not as an end in itself, but one tool to achieve greater quality in
certain circumstances. Of course - ultimately it's clear that we both
want a higher quality end-user product, and we just need good processes
that encourage contributions that (we can be sure) raise the quality to
get into the main-line as fast as possible.
Regards,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
