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

[Martin Pool]

2009/9/7 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
>    martin> Robert before seeing this thread, renamed 2.0 to
>    martin> 2.0rc1 and moved the remaining open bugs to 2.0rc2.
>
> I think that's the most reasonable thing to do... In the long term
> (as in looking back to previous releases in a coupe of years) I
> see bug <-> milestone relationship as a tool to ease support: I
> want to be able to ask for a bzr version used and reply with a
> bzr version to use.
>
> Having no milestone for a bug means a trip to NEWS, imprecise
> milestone means imprecise diagnostic (which is a pity for a VCS
> tool).

The ultimate check is to actually look at the code for that release,
and the second best is to look at the bzr records for it.  Anything
else is an approximation and whether it's the bug record or the NEWS
file it may be wrong.

This is especially true if you consider that bugs can be reopened, or
thought to be reopened but not actually need further fixing, etc.

> So I really want bugs assigned to the right milestone when they
> are *fix released*.

By which I assume you mean 'landed to the branch' as we use that
state, not actually released.

> Yet, until then the milestone may not exist. See
> https://bugs.edge.launchpad.net/bzr/+bug/412930 for example:
>
> - the fix has landed in bzr.dev,
>
> - I have no idea what the first release will be named in the 2.1
>  series. I can guess and create a 2.1beta1 milestone, but that
>  just feels wrong, it's months away.

It shouldn't be; it'll be a month after 2.0, approximately.  According
to our new plan it should be a month after 2.0 forked off, but I think
we need a bit of discretion in this case because of the intense effort
on 2.0 and the relative lack of trunk-specific landings.

> - I strongly prefer coming back at release time and re-affect to
>  the correct milestone... but that really sounds like RM
>  duty. Yeah sorry, I know we're trying to reduce the load there,
>  but cutting a release is also defining what will be in that
>  release, that means at least reading and editing NEWS and
>  probably writing a summary. Is that really demanding too much
>  that bugs be re-targeted appropriately (if needed !) ?

I think anything O(bugs_fixed) is an undesirable burden on the release manager.

I do think it would be interesting to have a script that helps them
reconcile the set of fix-released untargeted bugs with the set in
NEWS.

>
> The 'if needed' is important, apart from the example above, it
> shouldn't be needed for a lot of bugs during the whole series. As
> soon as the first release is made in a series, we enter a cycle
> where everybody knows pretty well what milestone he should be
> targeted, most of the time the branch were the fixes should land
> are discussed.
>
>    martin> I think renaming existing milestones is probably not
>    martin> a great idea
>
> I agree, it feels wrong. The alternative then is to re-target
> bugs. We can do that quite easily now thanks to in-place editing.
>
> <snip/>
>
>    martin>  * people can clearly see which bugs to work on next
>
> That's why I make a strong distinction between the milestone
> used to target or nominate the bug and the one used when the bug
> is fix released.
>
> \emphasize{They don't have to be the same.}

That's true, there is another approach:

 * target bugs to whichever final release (eg 2.1, 2.0) they will block
 * at the time of marking a bug fixed, retarget it to the rc or
release in which it was actually released, if that's different

Therefore you can see what changed in each rc

>    martin> * if someone wants to observe changes in a stable series, they should
>    martin> follow that series, eg
>    martin> <https://bugs.staging.launchpad.net/bzr/2.0/+bugs>
>
> Excuse my Klatchian, but I don't see what I want to see there. I
> see the targeted bugs. Where is the list of bugs fixed in the 2.0
> release ?

Well, obviously, you see the bugs targeted at a particular milestone
by looking at the milestone.

The question is, what do you really want to know by asking that
question?  Those were the things I was trying to break out in my
previous mail.  Another way to look at it is:

 * Is the release blocked? Check the milestone page for open bugs.
 * Are there any critical bugs I should do as the highest priority?
Check the critical bugs page.
 * What will be fixed in the next release?  Check the milestone page
for closed bugs - but this has the slight drawback that you may care
about bugs fixed in any of 2.0.*, but that's a bit hard to represent
at the moment.

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