Hi Michael,
many questions are answered by Mathias already. Some open questions
I want to answer.
Michael Meeks wrote:
As for the quality of OO.o 2.0.0 [ created AFAIR after the
specification process was introduced ], I think it was a fairly
'interesting' release (defect wise), hence the compound slippage etc.
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.
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.
Perhaps their bugs are of the form:
"OO.o is incredibly slow to start"
Yes this is a bug. But I think it is more than one bug.
Good unit testing [ as in I can run "dmake check" in configmgr and get
a yes/no answer in a few seconds ], such as I've implemented in previous
projects I've worked on [eg. the several thousand lines of unit test in
ORBit2] is invaluable. It helps re-factoring, it improves quality and
confidence in the product, and so on. Of course UNO components
substantially complicate such unit testing in OO.o (along with
(apparently) a love of only testing what can be tested via UNO, from
Java ;-). At least, I've not been able to understand the useful / common
recipe for running "do tests" or whatever in a given source directory &
getting useful data - I'd love to be shown how this works.
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. At UI level the automated testing with TestTool
is done. If the first levels are not done efficiently it will be more
difficult for the UI testing. Mostly the general stability is broken
or something else.
When we do have more testing on integration level will reduce the level
of UI testing with TestTool.
So - I need a deeper understanding of what you understand by quality
and how you weight these statements:
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
+ 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
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
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.
Regards,
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
