For the backlog of old resolved issues, I will do like this:
I will immediately close all issues that are resolved or verified in the
0.24 release or prior to that.
For issues that were resolved in the 0.25.1 - 0.26, I will send an automatic
message when doing the next release (tonight) with a date like two weeks
after tonights release.
/Linus
2008/9/13 Dave Thompson <[EMAIL PROTECTED]>
> Hi Linus,
>
> I suppose when I see 1000s of issues to be verified, I mentally calculate
> 20mins per issue * 1000, which is equivalent to approx 2 months of a full
> time job. Anyone can get a lot done in 2 months.
>
> My suggestions are:
>
> 1) Update the cookbook to say that issues can be optionally verified and
> closed after being resolved, but that this is not a requirement.
>
> 2) Remove the texts (cookbook/website) which encourage new developers to
> verify issues.
>
> 3) Send an automatic message out to every resolved issue when we do a major
> stable release, stating something like "This issue has been marked as
> resolved in time for release X. If nobody objects by reopenning this issue,
> is will be automatically closed [in 2 days' time / in 2 months' time /
> shortly before the next stable release]."
>
> 4) Close resolved issues that have not been re-openned after the period
> stated in 3).
>
> Regards,
>
> Dave
>
>
>
> Linus Tolke wrote:
>
>> 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] <mailto:[EMAIL PROTECTED]>>
>>
>> On Wed, 10 Sep 2008 23:21:31 +0100, "Luis Sergio Oliveira"
>> <[EMAIL PROTECTED] <mailto:[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]
>> <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
