change in fix-committed practice?

[Martin Pool]

2009/8/26 John Arbash Meinel <john at arbash-meinel.com>:
>> 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.

No, I do think, as you and Robert do, that we should use series and
bugtasks to track bugs that need to be fixed and released in multiple
series.

What I was responding to here is the issue of communicating which
releases have a bug or have a fix.

At the moment we slightly overload the milestone field to represent
1- up to the time we ship a release, the milestone in which we hope to fix it
2- after the fix was shipped, the release in which it actually was fixed

This is probably fine in practice though it does cause a little bit of
noise and has some slightly bad interactions with other Launchpad ui -
for example we actually want to target things on a coarse granularity
(like "in 2.0something") but mark them fixed precisely ("in 2.0rc1").

And on the other hand there's no formal way of saying "this was not
present in 1.16, it was introduced in 1.17 onward".  Launchpad have
talked about adding this feature which is called "infestation".  But
again, just plain text is enough for us.

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