[RFD] Milestone usage (Re: [Bug 422849] Re: Incorrect conversions in 2.0rc1 and bzr.dev)

[Martin Pool]

2009/9/4 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
>    martin> The practice in the past is to create them when you
>    martin> first want to use them...
>
> Oh, well. May be I was being a bit too much 'German' here :)
>
> I view milestone creation as RM duty because I think they are the
> core definition of the releases...
>
> Whereas targeting or nominating bugs is everybody duty.

That seems reasonable enough.

I think we need to define first just how we use them, and then it will
fit into the process docs pretty easily.  I do think having it done at
a defined time is better than ad-hoc, though I'd also like to make
'general setup' clearly separate from 'make a release' because the
latter is already enough work.


>    martin> I can't understand specifically what you want to
>    martin> change.
>
> Nothing now.
>
> I would have like that the bugs targeted to 2.0 were targeted to
> 2.0rc1 instead. Or that we rename the 2.0 milestone to 2.0rc1 at
> release time.

Robert before seeing this thread, renamed 2.0 to 2.0rc1 and moved the
remaining open bugs to 2.0rc2.

I think renaming existing milestones is probably not a great idea
because my sense is that's not really how the tool is meant to be
used, and it may cause some confusion either of humans or tools.  For
example if you look at
<https://bugs.edge.launchpad.net/bzr/+bug/385879> you can see the last
entry says "2.0 -> 2.0rc2" but it's targeted to 2.0, I guess because
it captures the name of the milestone at the time the change is made.
(And arguably showing the name as it then was is reasonable.)

I think the requirements are:

 * people can clearly see which bugs to work on next
 * the release manager can clearly see what bugs, if any, will block the release
 * users or observers can see what changed in a particular release
 * Launchpad is consistent with NEWS
 * minimum churn and work

What I suggest we do is:

* make milestones for every prospective release or candidate, ie
including 2.0rc1
* only target things that are really likely to block that release - so
the milestone view tells you about blockers
* do not rename milestones
* target blockers to the next release, even if that's an rc
* if someone wants to observe changes in a stable series, they should
follow that series, eg
<https://bugs.staging.launchpad.net/bzr/2.0/+bugs>

>    martin> As we discussed previously, we overload the target
>    martin> field to describe both when we aim to fix it
>
> We can use 2.0.
>
>    martin> and also when it was actually fixed.
>
> We should use 2.0rc1.
>
> Is that clearer ?
>
>    martin> If 2.0 final is on the 2.0 branch, and it will be,
>    martin> presumably the milestone should be on that series
>    martin> too, not on trunk.
>
> All milestones should be on the series, I never thought otherwise
> (I may have been unclear when expressing it...). I pointed to the
> pretty pictures to demonstrate that using milestones on trunk was
> given a strange[1] picture of the release process used.

One thing I found weird here is that you can apparently request a fix
in a series for a milestone that's not on that series; there's
something connected to
<https://bugs.edge.launchpad.net/malone/+bug/425465> here.

-- 
Martin <http://launchpad.net/~mbp/>