change in fix-committed practice?

[Martin Pool]

2009/8/26 Andrew Cowie <andrew at operationaldynamics.com>:

> I realize full well that the meaning of these terms and their usage is
> entirely an internal matter for the people hacking on Bazaar to decide
> how they interpret & how they use.

No, it's not really.  Other people read the bug tracker and we should
not make things unnecessarily hard on them.

I am open to changing this but it's quite separate from the issue
Robert was talking about here, which is really how do we represent
things targeted to stable releases.

'Fix commited' now that we use merge proposals is almost useless,
compared to saying "there's a branch that fixes it and its state is...
needs fixes/approved/merged."

We could use 'fix released' to mean really released.  Loggerhead does
this for example.

It requires a bot to flip them at the time of the release and this
generates some mail spam, as loggerhead just did.

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

I think that's the real reason why the status doesn't matter a lot to
people reading it.  What they actually want is "this is fixed in 2.0"
or "this will be fixed in the next release" and that's best expressed
by a text comment.

If lp tracked "fixed-in" and "present-in" as structured data it would
handle this.

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