Hi Mike and all,
I can understand some frustration with QA and overall with bug fixing
process. There are buggy features which are sometimes left as are for
many years (limitations of regular expression search & replace was just
such a feature for some years, to be started only two weeks ago...).
So let me rant as a developer.
Recent changes in patch handling processes seem to make the work of QA
and community developers easier. It's quite hard to change C++ code in
OOo - you need to setup the build environment, and in some OSes this
requires buying a lot of proprietary stuff (gcc is only starting to be
used, right?), and of course you need a lot of time etc. The process
isn't really modular.
But it's pretty easier to start working on script components - for
example, I fixed ugly bugs in a python script for e-mail merge, and in
two or three weeks they have been integrated into a bug fixing cws. The
script is still buggy (but usable at least) -- however, I need some
additional features which do not work as expected so probably I will fix
other bugs with this in the future. I already invested some 20 minutes
in that, and I'm ready for another 40 minutes to fix this ;)
This means that if it was easier to work modular, without compiling all
the stuff, and knowing all APIs, SDKs, etc., we'd have more developers.
This way we could manage the development of the complex system much
better. I don't know how to make the core code more modular, so this is
only ranting.
Anyway, even writing extensions is a big pain, as the docs are obscure
and not really helpful (I know what I'm talking about, I'm helping
Daniel Naber to develop grammar checker for OOo). I mean I could be able
to fix most simple bugs in OOo if the code was modular. But I don't have
all the time for setting up a 32-hours compilation process just to fix
one simple bug. So that's why community developers aren't really
attracted to the idea of fixing bugs. It's not sexy and it's painful,
and requires too much time.
just my 2 cents,
Marcin
Mike Hall napisał(a):
Thorsten Ziehm wrote:
Hello QA-Team,
the number of 'unconfirmed' defects increased in the last months to
nearly 1000 issues. It isn't possible for the Sun QA team to work on
all these issues alone. So the help of the whole team is needed.
Please visit my blog with some more details and links to queries.
http://blogs.sun.com/GullFOSS/entry/nearly_1000_unconfirmed_defects_are
Thanks
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/I understand the concern, however the cause may be partly a process
issue. This seems important - I spent a lot of time last night lying
awake thinking about it - please bear with the explanation below.
I take it as fundamental that everyone on this project is doing what
they believe to be right. The examples used below are intended to
illustrate the process problem, and are in not way intended as criticism
of individuals./
Several times in the last few months there have been comments about the
resolution of issues, the most recent of which was a message yesterday
by Laurent Godard about
http://fr.openoffice.org/issues/show_bug.cgi?id=3460
These cries from the heart seem to illustrate a fairly common if not
general disquiet with the issue process, underlying which is a sense
that the bug detection and correction process does not seem to set the
right priorities, especially in terms of deadline for bugs in categories
below P2, and as a result that the significant effort needed to
contribute to the quality process does not make a sufficient difference
to repay the effort involved.
For example, http://qa.openoffice.org/issues/show_bug.cgi?id=71957 was
an issue I found and spent several hours researching, considered at the
time as a 'feature'. Later, the problem was discovered independently by
someone with more influence, categorised as a regression, and fixed.
This is a clear example where my time was wasted. Now of course, in
processes as complex as they necessarily are within OOo, it's obvious
that some time is going to be wasted - it cannot be a perfect process.
However, there is a difference between feeling that 70% (ideally) or
even just 50% of ones effort is being used effectively, whereas my
current feeling is that 99% of what I have and might in the future
contribute would be a waste of my time, contributing primarily to a
stack of issues with completion deadlines of V3.0 or later which in
practice are unlikely to ever influence the development of the product.
'Ordinary' qa people like me need to feel that they have a direct
influence on priorities to make the effort worthwhile. For example, some
time ago I floated the idea of 'minimum acceptable functionality' as a
way of distinguishing the importance of certain bugs for fixing within,
let's say, the next two releases. There are no doubt a million other
ways to do it, but it seems to me that qa team members need to have the
authority to set the target deadline for a small proportion of issues
which are important to end users but not 'sexy' coding tasks for the
developers, even if the developers then set them back. Because this is
not available, it may be that many qa project people, like me, soon
become so disenchanted with the amount of effort for almost no result
that they end up just watching the correspondence on this distribution
list and not doing any work.
I don't pretend to know the best solution, but it is clear from where I
sit that the process is not fully fit-for-purpose and I plead with those
who are able to influence OOo processes to take this concern seriously.
I hope I have not spoken too much out of turn.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
