[rfc] Fix committed/released distinction

[vila]

>>>>> Martin Pool <mbp at canonical.com> writes:


    >>  - having stuff visible where there is a special process for getting
    >> it to users is good.

    > Yep.

I may be missing the point but I routinely use the milestone pages to see
which bugs are targeted to them:

 https://launchpad.net/bzr/+milestone/2.4b2

for example clearly shows which bugs will be fixed by our next beta and
even mentions:

  #741760 "bzr merge" always looks at revision graph  Critical Jelmer Vernooij In Progress

(sorry if this comes out badly wrapped, see the page, that's the first
bug in the list) emphasis on "In Progress" here.

For the previous (as yet unreleased) series, this gives:

  https://launchpad.net/bzr/+milestone/2.3.2
  https://launchpad.net/bzr/+milestone/2.2.5
  https://launchpad.net/bzr/+milestone/2.1.4
  https://launchpad.net/bzr/+milestone/2.0.7

Also note that I try to keep the expected release dates up to date (so
you can decide from these pages whether a release with a fix is
available or when it will be available).

The links to these pages are available right from
https://launchpad.net/bzr/ in the 'Series and milestones' part of the
page.

So, 1) Kudos to launchpad devs for providing this, 2) Why don't we just
use that and file bugs if some needs are still not covered ?

But to come back to the committed/released distinction, when we used
that, there were *more* confusion about whether the fix was available or
not from our users than today (subjective feeling).

This may be because our release process has matured and we better triage
bugs, but even without that, what matters for the user is: which release
should I use to get the fix and that's always what we answer: use
release x.y.z or series x.y.

The bug <-> milestone relationship sound more important to me than the
distinction between committed and released.

So I'd be in favor of keeping only released and pursue our efforts on
creating bug tasks when we backport fixes (or daggy-fix them, whatever).

And to come back to the kanban, can't you use the bug/milestone
relationships to decide whether a bug is released or not ? Taking into
account that a bug can be technically released by series *OR* via a ppa
(daily builds), which is what users care about ?

    Vincent