Re: bugs -> release milestone policy

[Luis Villa <louie ximian com>]

On Tue, 2002-10-29 at 15:09, Andrew Sobala wrote:
> > > What do you think?
> > 
> > Let's try again, then- 
> > 
> > VERGNO1.4.x
> > VERGNO2.0.x
> > VERGNO2.1.x
> > 
> > TARGET2.0.3
> > TARGET2.2.0
> > TARGET2.2.1
> > etc.
> > 
> > I'm not sure how well these read; VERGNO seems pretty ugly to me.
> > 
> > [is target more clear than milestone? Just a random thought- milestone
> > is sort of a mozilla-ism as much as anything else.]
> 
> OK, I posted all that because I didn't know what the difference between
> the VER and MILE was. I get it now and we're actually just talking about
> the same thing, just the naming.
> 
> I like TARGET. I agree VERGNO is ugly. Assuming the relevant people know
> about this change, I wouldn't be against calling it GNOME:
> 
> GNOME2.0->GNOME2.0
> GNOME2.1.x->GNOME2.1
> GNOME2.0.[1|2|3]->TARGET2.0.[1|2|3]
> GNOME2.2.0->TARGET2.2.0
> 
> But are the costs of making sure that this new usage of an old keyword
> isn't misunderstood too high to be practical?

Well, you're talking about a keyword that has been used thousands of
times, so I can understand why it would seem like a high cost. However, 
literally 95% of the time they were used by me. :) So... the
re-education cost is pretty low, especially given that it's very clear
that even many active bug-hunters didn't understand them the first time
around. I can do the changes directly in the database so no spam cost,
either.

> A second point: At this point in time, should 2.2 bugs be targeted
> TARGET2.2.0 or should we have a TARGET2.2 keyword as well? The
> difference would be:
>
> Scenario 1
> ----------
> 
> 2.2 bugs get keyworded TARGET2.2.0
> As we get closer to the release, some get punted and immediately get
> rekeyworded TARGET2.2.[somenumber]
> 
> Scenario 2
> ----------
> 
> 2.2 bugs get keyworded TARGET2.2 (really serious ones TARGET2.2.0)
> As we get closer to the release, some 2.2s are obviously "must fix" and
> get keyworded TARGET2.2.0. Others get keyworded TARGET2.2.[somenumber]
> ie. punted.
> 
> Basically, in scenario 1 we use a TARGET2.2.0 keyword now and assume all
> bugs will be fixed by 2.2.0 unless they get punted. In scenario 2, we
> use a TARGET2.2 keyword now and assume it's too early to assign
> third-dot targets.
>
> I vote for 2 because I think that keywording 2.2.0 now would result in a
> uselessly large number of 2.2.0 bugs that would spam a developer's query
> for them.

Let me suggest a third option. It is roughly what I did for 2.0;
versions have been changed to protect the innocent.

*add GNOVER2.1 to all 2.1-specific bugs as appropriate, including
prioritization. Difference from either scenario above: No TARGET keyword
is assigned at this time, 'just' priority. In this sense, priority of
high or greater is roughly like Andrew's TARGET2.2 keyword.

*when we get closer to release (probably early december), everything
'high' priority is reviewed and assigned TARGET2.2.0 or TARGET2.2.x;
after 2.2.0 everything with 2.2.x as well as new bugs are reviewed and
possibly moved to 2.2.1.

I'm not sure that this is the best way- it involves a lot of very
time-intenstive review late in the process. What do you guys think? The
mechanism I just described worked for me, but I'm not convinced it's the
Best Way.

Note that this discussion doesn't clarify how to handle the 2.0.x and
2.2 split- i.e., can we or should we have bugs that are both TARGET2.0.3
and TARGET2.2.0? Or bugs that are both GNOVER2.0 and GNOVER2.1? I'm not
sure what the best solution is for that, to be honest- I've got very
little experience with it.

Luis