Hello Dave!
There were two reasons for setting up the process as it is. The first one is
that the Tigris infrastructure doesn't allow us to remove the states in the
lifecycle. The second one is that I had the idea that verifying issues would
be a good way for non-java persons and persons that are new to the project
to understand how we work with issues.
The first reason is still valid. It won't be possible after the Tigris
upgrade either.
The second reason, I must admit that the idea never really caught on.
On the other hand, I don't think that changing this would immediately
increase the amount of useful work considerably since there isn't that much
work that goes into verifying issues.
What is the concrete suggestion? What of the following should we do?
- Remove the process of verifying and closing issues to make RESOLVED,
VERIFIED, and CLOSED equivalent.
- Stop mentioning the option of verifying issues when joining the
project.
- Close all issues currently RESOLVED or VERIFIED and the close them
regularly, probably connected to the release work. Something like a couple
of days after a stable release or something simpler.
/Linus
2008/9/11 Dave Thompson <[EMAIL PROTECTED]>
> On Wed, 10 Sep 2008 23:21:31 +0100, "Luis Sergio Oliveira"
> <[EMAIL PROTECTED]> said:
>
> > Currently, when an issue is resolved, you have the developer's opinion
> > it is fixed. It is already good, but, why not allow it to be verified
> > afterwards and have a supporting issue life cycle that is capable of
> > registering that?
>
> The reason is to reduce non-useful work, allowing that time to be spent
> on other things.
>
> If verifying an issue is something that is optional (it sounds like it
> is), then we should have that as a policy clearly stated in the
> cookbook. In my opinion, verifying issues should be a lower priority
> than most of our P5 defects. If a person feels strongly about an issue
> he reported (or cc'd himself on), he will check it when it is marked as
> resolved. If no-one feels strongly about an issue any longer (e.g.
> original reporter left the scene and no-one else was cc'd), then what is
> the problem with accepting the developer's opinion that it was fixed?
>
> There is a difference between an idealistic workflow and a realistic
> one. The problem is that idealistic workflows often depend on ideal
> amounts of resource, and are often unnecessarily complex.
>
> Regards,
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
