Hi Thorsten,
On Wed, 2006-10-25 at 13:23 +0200, Thorsten Ziehm wrote:
> Nobody said, that it is needed to include _burdensome_ processes
> to get a higher quality.
Wonderful, so making the process less burdensome is possible. Great -
so, lets get the design requirements for the specification process all
collated in 1 place, and then try to make a much less burdensome
process :-)
> 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?
Did I say we should give up our high living standards ? ;-) of course
we need -some- process; ideally though it should be one that is minimal
[ ie. requires the minimum effort to achieve the maximum benefit ], and
simple to use. Furthermore, there needs to be a get-out clause for
external contributors, at least for their first <N> features, and
finally it needs to not rely on people being responsive :-)
> 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.
From my experience (of back-porting, sometimes critical, fixes from the
680 branch back to OO.o 1.1.x) the -primary- driver of improved quality
in OO.o 2.0.<x> has been the switch to frequent releases, and not the
introduction of painful, and change inhibiting processes. The frequent
release means that people do their fix once and get it included in the
product shortly afterwards, instead of having to worry if it's critical
enough to get back-ported.
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.
> I think this is one reason why OpenOffice.org is so successful.
Do you have data to back that up ?
> 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?
Perhaps their bugs are of the form:
"OO.o is incredibly slow to start"
:-) is that not a bug ? or perhaps they are bugs about ergonomic
problems - is it fixing a bug or adding a feature to make some minor
(unusable) corner case usable ?
> That's not the point. It isn't possible to check the quality of all
> integrated code by the Sun QA team.
Which is strange. At least, from where I stand we need more quality
[ by which I mean all-around polish ] not less; from a UI perspective we
need thousands of tiny ergonomic fixes all over the place: almost all of
them trivial in and of themselves; but if each one requires a multi-page
specification, they will never get done.
Furthermore, I find the quality of the QA tests generally rather poor.
My recollection (which may be wildly astray) is that broadly there is a
large list of StarBasic test cases [ which is good ], but many of these
are known to fail / spit warnings, they take several (3+) -days- to run
(mostly with the machine idle / sleeping), and they're not particularly
reliable :-) [ is that unfair ? ]
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.
> 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.
So - if maintaining a constant quality level is what matters would you
trade higher quality code (ie. peer reviewed code) for some reduction in
of code-duplication-as-paper-work [ the spec. burden ] ?
> 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 ?
The problem is you are retarding not just features, but fix inclusion.
This was dramatically the case with the old-style 1.1.x branch: the cost
& penalty of back-porting *fixes* was so high that only very
infrequently did people bother to actually do it, consequently the
quality of the 1.1.x branch stayed low.
My feeling is that -if- you can be sure that commits will (on average)
fix more than they break, and that you can be sure critical regressions
are extremely unlikely then accelerating the pace of change will lead to
higher quality :-)
> I heard some customers and they
> told, that they want to have higher stability and higher quality.
So - I need a deeper understanding of what you understand by quality
and how you weight these statements:
+ Quality is OO.o not crashing (stability)
+ Quality is OO.o not loosing data
+ Quality is OO.o behaving ergonomically as I expect
+ Quality is OO.o loading & saving my 'foreign' data files
+ Quality is OO.o being slick & beautiful
+ Quality is OO.o performing acceptably
+ Quality is OO.o not consuming all available memory
+ Quality is OO.o being feature competitive with others
+ Quality is every aspect of OO.o having a detailed spec.
+ 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
> 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.
Are you suggesting that on occasion StarOffice chooses a lower quality
than OO.o in order to satisfy specific customer feature requests ? if so
I think that's screwed up ;-) OO.o should be of a lower quality in order
to get great testing & feedback to improve the StarOffice quality; at
least that is how I would structure it. Indeed - I am surprised that
OO.o and StarOffice releases are ~concurrent (or that StarOffice
sometimes leads) - that seems to me to be a recipe for poorer quality in
StarOffice.
Anyhow, some food for thought ?
Regards,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
