Thorsten,
Thanks. I understand all of that, but nevertheless it's arguable that
the process does not work as well as it could.
I accept your challenge "If you have a proposal..." I have a glimmer of
an idea and some (actually quite a lot) of relevant experience. Give me
a couple of weeks while we are away to mull it over and write something
sensible down.
Mike
Thorsten Ziehm wrote:
Hi Mike,
you talk about the "little" issues. Especially these issues should be
addressed with the change to general owners. It is a question of
resources. And is wasn't and it isn't possible for the responsible QA
engineers inside the Sun Team to work throw all incoming issues in time.
Therefore the issues are on general owners, which should identify, that
everyone in the community can work on it and can raise it as important
or close it, when it isn't a real issue.
Currently there isn't a better process or any other solution, I know. If
you have a proposal how to handle it better with the existing resources
write it down and propose it here. But I do not see any chance to set
Sun QA engineers as default as in the past. If they work on all incoming
issues in time, they will not have the time to work on new incoming
features/bug fixes etc. So the help from community is need to work on
one of the topics regularly.
One comment to your samples. I do not check the issues, but I belief
that they are regressions. But as for general bugs it isn't possible
to fix all regressions. The resources in development of OOo is also
limited. Therefore 'little' issues are fixed sometimes 'accidentally'
with enhancements or changes in that area. But often these issues
are set on a lower priority and perhaps on 'office later' target.
And yes, this will mean, that the issues are never fixed! As I wrote
it is a question of resources for the whole project.
Regards,
Thorsten
Mike Hall wrote:
Thorsten,
Thank you for your careful reply.
I agree that major issues are generally picked up by the process and
I have escalated at least one from these forums. Those are not a
problem and that all seems to work fine.
My concern was more about the little issues, which don't really
warrant discussion here, but still need fixing and, if they are
regressions, are quite likely to be easy and desirable to fix
quickly. The example i#93577, is a minor but irritating regression,
and the one I "shouldn't" have escalated the way I did. No doubt that
will now get handled appropriately.
To illustrate that the process doesn't always work, you could look at
#88626. That was a similar minor regression, marked as such, but I
deliberately left it to be taken care of by the process. In the end
nothing at all happened. After around 4 months, when I retested, it
had been independently fixed, so I closed it. There is no evidence
that anyone else ever looked at it, though of course they may have.
From this end, whatever work was done did seem to be a bit of a waste
of time. What perhaps is needed in the process is that there is
always at least one response, so that the qa originator is aware that
the issue has been noticed. I felt that that was more likely with the
previous process, but perhaps I'm wrong.
These are just examples, and not at all important in themselves, but
they do illustrate the point. I'd be surprised if there weren't other
similar examples. The main point I want to make is that it shouldn't
be necessary for the originator to have to follow up on these kind of
issues, particularly minor regressions. It would be better if the
process took care of them.
Mike
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mike Hall
www.onepoyle.net
