A lot of mails have been sent by the issue system. I have closed all issues
up to 0.18.1 sofar. I will get back to this later.
/Linus
2008/9/13 Linus Tolke <[EMAIL PROTECTED]>
> 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]
>>
>>
>
