Hi Drew,
Further, I suppose it is reasonable that a person should make note
of the fact that a defect marked as resolved but not given a target
milestone is not in the queue to be released.
when the task was fixed and the corresponding cws was created
only OOo 2.0.x and OOo Later targets were available. I think
the cws target should and will be changed to OOo 3.0, but this
makes no sense before integration of 3.0 cws starts.
But Bernard has a very valid point also. This is an issue that has been
such for over 18 months,
most of the time waiting for a developer to get to it. Let me rephrase
that, waiting for a developers
time to become available. This included releases from 1.0.0 - 2.0.1.
Hardly just
maintenance releases. Given the overall length of time involved it is
reasonable to expect that
retarding release once it is fixed, and one would asume has passed unit
and regresson testing,
is not going to go over well.
In this context I don't see any relevance in the time a task is
waiting to be fixed. Unfortunately there are many task such old
that haven't even been fixed yet just for lack of time to do so.
This task only has been fixed, because - when reproducing it -
I realised that it was very easy to fix and directly did so.
But regression testing can not start after fixing a task but only
after the fix has been integrated into the master. The policy not
to integrate every fixed task into a maintainance release targets
to avoid regression _before_ it comes into the master because not
all regression problems can be found there as testing never can
cover 100%.
If I might make a suggestion, when weighing the risk/benefit factors -
length of time that the issue has been
open be taken into account. In a situation like this if a fix is deemed
to risky for release - at least try and
see if a reasonable target can be set. The ambiguity of OOLater for an
18 month fix is a bit much.
It's not the problem, if this single fix is too risky for release.
The problem is that there could be hundreds of such "riskless"
fixes. If you asked a developer for the risk of fixes hardly any-
one would judge most of his fixes as risky as of course everyone
thinks he has done good work. But as Frank said there are always
fixes that do provoke a regression.
So the policy is to reduce the amount of fixes beeing integrated
into a maintainance release. And this task has - IMHO correctly,
as there's a workaround - prio 4 that is generally not accepted
for such targets. Maybe in this special case it could be integra-
ted without risk but the cws ab19 contains 12 other fixes. Why
shouldn't they be integrated all then? I don't see why the task
we are discussing about should be more important than any other
one fixed there - at least not before this discussion. And then
we again have hundreds of fixes to integrate into a maintainance
release and some of them will bring regression. There has to be
a simple rule to limit the amount of fixes without judging every
one in detail. I see no alternative.
But of course I will have another look at this concrete task now
as there seem to be some more interest and maybe it then can make
it into 2.0.3 as a "customer escalation" as Frank proposed in the
meantime.
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
