change in fix-committed practice?

[Vincent Ladeuil]

>>>>> "Andrew" == Andrew Cowie <andrew at operationaldynamics.com> writes:

    Andrew> On Wed, 2009-08-26 at 14:48 +1000, Martin Pool wrote:
    >> I don't think we should change the meaning of fix committed and fix
    >> released.

    Andrew> A comment from an interested outside observer:

    Andrew> The way you use these terms doesn't mean what I think it means.

    Andrew> 1. fix committed

    Andrew> doesn't mean anything (or rather, it is vulnerable to meaning any of a
    Andrew> number of things).

    Andrew> I think the way you use it implies "fix-exists".

Yes, and generally the bug has a branch associated with it. If it
hasn't, the bug assignee missed a step.

<snip/>

    Andrew> 2. fix released

    Andrew> Release is a very strongly defined term. It means
    Andrew> tarballs have been cut. We all know this.

    Andrew> Which is why I'm a little perplexed that
    Andrew> "fix-released" seems to indicate that a branch with a
    Andrew> fix has been merged to 'mainline' / trunk / bzr.dev /
    Andrew> whatever. And certainly, in a world with two major
    Andrew> streams, it's even more confusing. Doesn't change the
    Andrew> fact that we haven't answered the question: which
    Andrew> *release* is it in? Huh? It's not in any release yet?
    Andrew> How can it be "fix-released" then?


Right, it means the fix is in the tarball of the release
indicated via the milestone.

The fact that some milestones haven't (yet) a tarball is irrelevant :)

If no milestone has been specified, again, the bug assignee
should get what he deserved :)

All of the above is described in doc/developers/bug-handling.txt.

We may want to publicize that more broadly as indeed, users are
facing it as much as developers.

       Vincent