Comment 8 for bug 163694

2009/8/28 Robert Collins <email address hidden>:
> @intellectronica this seems orthogonal to tasks-in-projects.

I agree, and also agree mpt's description is very nice.

It seems to me that projects track this at present by just putting
freeform text into the closing comment on the bug.

If people want to distinguish between "fix exists" and "fix has been
merged to the release branch", which is the main thing we previously
used fix committed vs released for, then they can do that with merge
proposals.

> (1) "Fix Committed" and "Fix Released" be merged into "Fixed";

I think this can usefully be done independently of the others. They
would all be useful but I don't think fix committed vs released very
tightly relates to any of them - for example users deduping bugs are
as likely to have an old release as to have the current release and
hitting a fix-committed bug.

> (2) a text field be introduced for bugtasks, so developers (and Soyuz) can record the version/versions in which a bug was Fixed;

This is like structured infestation?

> (3) project maintainers be able to configure how long a bug report remains visible in default search results after the bug is Fixed (for Ubuntu this might be 12 months, while for Launchpad itself it could be 60 days);

That would rock, and I think even just starting with a global
arbitrary six-month "recently fixed" category would be a start and
would give some data on whether it's useful.

> (4) the "Is the bug you’re reporting one of these?" list treat bug statuses just like the normal search does, including fixed bugs only if they were fixed recently.

And see also <https://bugs.edge.launchpad.net/malone/+bug/277352>.
Perhaps eventually all searches should include recently-fixed bugs.
(Or perhaps even on a different timescale - bugs fixed last week are
likely still interesting, bugs fixed a year ago are generally not
relevant.)

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