Hi Michael,
them: "We need this burdensome process for Higher Quality !"
us: "But lets face it quality is still not good"
them: "Then we need -even-more- burdensome process !"
<repeat ad nauseum.>
Nobody said, that it is needed to include _burdensome_ processes to get
a higher quality. If all people who worked on such a big and complex
project like OpenOffice.org could take enough care of quality on each
new integrated code quality assurance, other control mechanism or
processes are not needed. And there isn't a difference between new
feature or a bug fix. But in the past years especially _I_ learned, that
it is easier to bring in a mass of new features as to bring in stability
and high quality into the product. The project OpenOffice.org is too
complex, that somebody can have an overview about all dependencies.
Because of the hard work to get a higher quality from one Update to the
next one, some leaks in work flows were identified. And to avoid the
such problems some processes like the New Specification Template were
introduced.
All over in the industry you see processes and control mechanisms.
Without that we are not in such a high living standards. So why the
Software industry and OpenOffice.org should give up processes and
control mechanisms?
That the quality is still not good you are right in some cases. Yes we
have still more then 9000 issues open. Nearly 6500 issues are defects.
But in my opinion OpenOffice.org 2.x is more stable and is more usable
and more bug free than ever. We still have problems in special areas,
where people can say OpenOffice.org is still in Beta status. But the
general work for private and business use the Office has a very high
quality.
I think this is one reason why OpenOffice.org is so successful.
If somebody think the quality isn't high enough, why they are working on
new features and why they are not working on fixing bugs?
That if Sun QA
wants to include all this process for Quality reasons, then -it- must
shoulder the burden [ at least for volunteer contributions ].
That's not the point. It isn't possible to check the quality of all
integrated code by the Sun QA team. Therefore processes are defined
(e.g. how to approve a CWS), that every community member and developers
can help here. If there aren't any definition or tools to help making
QA, it will not be possible to handle so much code changes.
One point was not understood over years at StarOffice team at Sun and
other software products around the world. The Quality Assurance cannot
bring quality into the product. The developers bring the quality into
the code and the QA have to make regression testing. If the quality of
the code is bad, the QA cannot make out of it a good product. So the
code must be better and the documentation about the changes, because
then regression testing is more efficiently. That's one reason why the
specifications are needed.
Having a formalised process (1 paragraph necessary?) for quickly
including code into OO.o that is disabled in all Sun builds, and quickly
getting fixes / changes into that etc. would be much appreciated. This
is something we have been wanting for some years now; but no action.
I learned from the past quality takes time. If you want to have
quick fixes and changes into a code line, the quality will decrease.
What do you want to have, a product with higher quality or a product
with much more features and changes? I heard some customers and they
told, that they want to have higher stability and higher quality. But
you will be right, additionally they said, they want to have feature
xyz. But often these are features, which are very special for they needs
and has nothing to do in an open source project like OpenOffice.org.
That's why Sun and other companies make an own brand of OOo.
Regards,
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
