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

Martin Pool mbp at canonical.com
Fri Sep 4 00:48:27 BST 2009


2009/9/3 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
>>>>>> "robert" == Robert Collins <robertc at robertcollins.net> writes:
>
>    robert> ** Changed in: bzr
>    robert>        Status: In Progress => Fix Released
>
>    robert> ** Also affects: bzr/2.0
>    robert>    Importance: Undecided
>    robert>        Status: New
>
>    robert> ** Changed in: bzr
>    robert>     Milestone: 2.0 => 2.0rc2
>
> <snip/>
>
>    robert> ** Changed in: bzr/2.0
>    robert>     Milestone: None => 2.0rc2
>
>    robert> ** Changed in: bzr
>    robert>     Milestone: 2.0rc2 => 2.0
>
> When I received that mail I wondered for a minute what was going
> on.

You may not be seeing it here, but there is a bug in malone's mail
sending where they way it's described doesn't make sense in the order
it's read.  There is a bug for this but I can't find it at the moment.
 If it looks wrong, look at the web ui.

But I think here you're talking only about how we use milestones?

>
> So go see https://bugs.launchpad.net/bzr/+bug/422849 first.
>
> That bug has been fix released in 2.0.
> But in 2.0 it has been fix released in 2.0rc2.
>
> That's true and I think it's a valid way to represent that and it
> was important that this was clearly described.
>
> That being said...
>
> When I made the 2.0rc1 (instead of beta1 but the problem would
> have been exactly the same), I wondered for a minute about:
> - reassigning all bugs to the 2.0rc1 milestone,
> - rename the 2.0 milestone to 2.0rc1,
> - leave things as is to keep a clean list of all bugs fixed for
>  the 2.0 series
>
> I did the later (if only because it meant doing nothing at all),
> but I'm not convinced it was the wisest choice.
>
> One cause is that we tend to create milestones too late (as I
> tried to point out in
> https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854),
> milestones should be created in sync with changing version_info
> in bzrlib/__init__.py and creating the right section in NEWS[1].

The practice in the past is to create them when you first want to use them...

>
> There may also be in bug in launchpad that we can't look at all
> the bugs fixed in a series (as opposed to a milestone). This view
> can be the sum of the bugs fixed in all milestones.
>
> The best we have today is:
>
> https://bugs.launchpad.net/bzr/2.0/+bugs?search=Search&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed&field.status=Fix+Released&field.status=Invalid&field.status=Won't+Fix&field.omit_dupes.used=
>
> Ugly URL and wrong result :-/
>
> Compared to:
>
> https://launchpad.net/bzr/+milestone/2.0
>
> So I think we want to always target bugs to the right milestone
> and 2.0 wasn't one.
>
> That's no big deal and I don't think we need to change anything,
> I just want to raise the problem and discuss whether or not we
> want to change that.

I can't understand specifically what you want to change.

As we discussed previously, we overload the target field to describe
both when we aim to fix it and also when it was actually fixed.

If 2.0 final is on the 2.0 branch, and it will be, presumably the
milestone should be on that series too, not on trunk.

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



More information about the bazaar mailing list