change in fix-committed practice?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

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

So why not use release series for this sort of thing. So if it is "Fix
Released" in the generic bzr target, then it is fixed in trunk/the last
beta release.

If it is "Fix Released" in the 2.0 stable series, then it can have a
separate line targeted at that series, and marked Fix Committed when it
is in the 2.0 stable release branch, and Fix Released when that is packaged.

Maybe I'm misunderstanding, but I thought that was part of the whole
point of having multiple targets on a bug.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqVPeQACgkQJdeBCYSNAAM4dACeMT3hzOVRYIpxOdavmpmSo9Vo
McgAn2cRmqPSFBnxDlo0iPOw81qBeF47
=1LVA
-----END PGP SIGNATURE-----