[Tracker-discuss] Feature/Change request handling procedure

[Stefan Seefeld]

Martin v. Löwis wrote:
> Stefan Seefeld schrieb:
>> I'm a bit confused now (about Martin's use case): I suggested milestones
>> to replace priorities with much stronger semantics, as this would allow
>> to express the relationship of 'this bug needs to be fixed before that
>> milestone is complete'. What you, Erik, suggest here with a fake bug
>> and the dependencies property sounds like an attempt to do the exact
>> same without having to introduce the 'milestone' issue type.
> 
> No, it's not the exact same. With a milestone system, I understood that
> you would associate each bug with a milestone. With the release
> blockers, only selected few bugs block a release; most bugs never block
> any release.

I see. Well, as Erik suggested, the links from milestone to bugs could be
annotated, i.e. for some bugs being set in a milestone are mere
estimates, for others they are hard requirements.

You could equally well use the milestone type to only list those bugs
that are strictly required.


> 
>>>>> See above. In open source, it is really unrealistic to assume that
>>>>> a bug can be fixed with a given deadline. It may well take years
>>>>> to fix a certain bug even if the bug is critical in some contexts.
>>>>> Even for patches, we now have patches that have been completely
>>>>> unreviewed for more than three years. So setting target versions
>>>>> is just day-dreaming.
>> So how does this compare to your statement above that an issue may
>> block a release ?
> 
> Like so: if we have a true release blocker, we can't release. If
> nobody fixes the blocker, we can't release, period. It's not that
> we tell somebody "fix it by this and that day", but instead,
> we tell everybody "if it doesn't get fixed, we can't release".

Right, that's exactly what I have in mind with my 'milestone' proposal.

> In many cases, this encourages some volunteer to contribute a fix.
> In some cases, the release manager then may decide "maybe it isn't
> a release blocker, after all"; there are no hard criteria for it.

...in which case he would remove it from the milestone.

> In other cases, the release manager himself fixes it, just so that
> the release can proceed.

even better. :-)

> 
>>> 2) Re-add the 'priority' field, to allow python-dev to use it as used
>>>    before (to show if an issue should be included or not in the next
>>>    release). We could add the extra twist that only people with the
>>>    developer role can change it.
>> Here I disagree, or at least, I ask for clarification: either it is important
>> to be able to tag blockers, in which case milestones seems to be a much
>> better approach, or it isn't, in which case priorities don't really add
>> anything. Can someone please help me see the light ?
> 
> I doubt it, somewhat. I, too, see the introduction of milestones as an
> unnecessary complication, because I don't see how they should get used.
> Its more a gut feeling "please leave this simple", than any objective
> evaluation. I understand that it is easy to introduce such a feature
> later.

I agree.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...