Noting my proposal from #darcs for wider discussion. Currently we have 13 issue 
statuses. About 7 of those should go I feel, but this proposal is just to drop 
the 
resolved-in-stable and resolved-in-unstable statuses, and to use the resolved 
status 
instead. Reasons for:

- they are relative, not absolute, so keep having to be updated manually.
Except right after an update, these fields are always more or less out of date.

- the update process has been semi-automated but requires relearning the 
scripts, 
checking that nothing went wrong, and some of my time and attention, which will 
not 
always be available promptly. This feels like labour that would be better spent 
on 
other things.

- they are overhead that don't justify their existence. I believe we can get by 
just 
fine with resolved, using the bug dates, known release dates, and comments to 
know 
where to expect fixes to appear.

- if truly needed, we can add a separate released-in-version: X.XX field. This 
is 
easy, however let's not do it until the need bites us in practice. YAGNI.

The short comment to this is: I understand it as the responsibility of the issue manager (currently myself) to ensure 
that these statuses are up to date. But since I haven't gotten to a stage yet where I can understand most of the total 
process, I would prefer things to be left as they are for the moment. When I become more comfortable with matters, I 
will not hesitate to raise the issue again.

The longer story: There is a clear problem with an indicator, such as the status field in the bugs tracker, that is 
mostly (or competely) redundant, in the sense that it is simply supposed to summarize some actual events that may not 
even be evident from the issue itself. And which therefore needs to be maintained by hand. The other problem, as I 
experience it, but I may have overlooked something, is that the meaning and use of the status codes are not 
particularly well defined. This leads to confusion when some code is interpreted to mean different things or used to 
tell different stories by different people.

If there is some easily accessible description somewhere that explains how the various status codes are supposed to be 
used, I have failed to find it. There is http://wiki.darcs.net/DarcsWiki/BugTracker, of course, but although it 
contains useful thoughts and ideas, it is not the finished thing.

Deciding on which status codes we should have and how they should be used must be seen in a broader context of how we 
actually work, change things, report events and so on. I will certainly try to get into a position where I understand 
these things better and then, hopefully, help to do them better.

Best regards Thorkil

I'll just also mention that the date is insufficient to determine the status of
a bug.  In particular, the distinction between resolved-in-stable and
resolved-in-unstable is real, and can't be disambiguated by date.  It's also
something that can be automated, if Eric would like to do so, and which he could
conceivably use to help decide when fixes should be moved into stable from unstable.

On the other hand, a simpler approach would be simpler.

David

Thorkil: now that you've had some time to gather your thoughts on bugtracking,
is there any action you would like us to take on this?

I've gone ahead and done this: 

roundup-admin -i /var/lib/roundup/trackers/darcs
list status
retire status10
retire status12
commit