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

[Vincent Ladeuil]

>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:

<snip/>
    >> 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.

    martin> That seems reasonable enough.

Ok.

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

Yup. That's where we still have a tension.

    >>    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.

    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).

So I really want bugs assigned to the right milestone when they
are *fix 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.

- 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 !) ?

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.}

    martin>  * the release manager can clearly see what bugs, if
    martin>  any, will block the release

Targeted ones.

    martin>  * users or observers can see what changed in a
    martin>  particular release

Fix released ones.

    martin>  * Launchpad is consistent with NEWS

With this proposal yes.

    martin>  * minimum churn and work

If you include the time spent checking when a bug was fixed,
certainly.

    martin> What I suggest we do is:

    martin> * make milestones for every prospective release or candidate, ie
    martin> including 2.0rc1

You can do that for the *first* possible milestones (which makes
sense since after all, we don't plan ahead to have several betas
nor several rcs, these ones can be created when we decide to have
the associated releases).

    martin> * only target things that are really likely to block
    martin> that release - so the milestone view tells you about
    martin> blockers

Hmm. 'block' sounds a bit too much here, if you start working on
a bug, or fix release it, you can still use the right milestone.
Other than that I agree.

    martin> * do not rename milestones

Agree.

    martin> * target blockers to the next release, even if that's
    martin> an rc

Sounds reasonable, they can always be re-targeted and indeed that
will be RM call.

    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 ?

        Vincent

P.S.: Almost off-topic is the fact that you can re-activate a
milestone if you want to assign or modify a milestone for a given
bug. I discovered that recently and I know at least jam and I
have often commented on bugs saying: I set milestone X but it's
really Y.