Flyspray - The bug killer!

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra

This is the Bug Tracking System for the Flyspray project. This is not a demo! Before opening a new task, please read the guidelines!

Do not issue bugs reports against versions earlier than 0.9.9.5

Security problem? Check the security section.

Tasklist

FS#496 - 'Released' flag / status level

Attached to Project: Flyspray - The bug killer!
Opened by Simon Large (slarge) - Tuesday, 29 March 2005, 00:10 GMT+1
Task Type Feature Request
Category Backend/Core
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 0.9.7
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

We encourage our users to look at the issue tracker so they can see what
has been fixed and not keep sending bug reports for a bug which was
fixed just after the last release. In order for them to see those closed
issues, our default view of the bug tracker shows all statuses, but that
then means we can’t filter out things that have already been included
in an official release.

I notice a similar thing in your own issue tracker. Having the
percentage-complete updated to 100 on issue closure appears 3 times and
it has already been fixed in HEAD, although it’s not in the current
0.9.7.

Can I propose another flag ‘Released’, which means ‘I have made it into
the official release’. Closing an issue does not set this flag. You can
then add another filter ‘Open & unreleased issues’ (bit of a mouthful)
which displays all open issues and any closed issues which aren’t yet
available in a public release.

The flag would have to be set manually, or there could be an
administrator function which lets you set the flag for all closed issues
when a release is made.

It could be implemented as another status level as long as it doesn't
interfere with task interdependence.

This task depends upon

Closed by  Mac Newbold (macnewbold)
Tuesday, 22 November 2005, 21:15 GMT+1
Reason for closing:  Deferred
Comment by Mac Newbold (macnewbold) - Friday, 20 May 2005, 22:05 GMT+1

This sounds to me like a useful feature, if the UI issues can be worked out.

I’d suggest having Open & Unreleased as well as plain old Unreleased, since I’d most likely close an issue when it was fixed, and then before a release, I’d want to check the unreleased changes to make (or compare with) a change log document.

Comment by Nathan (Nate) - Tuesday, 07 June 2005, 09:48 GMT+1

Couldn’t this get handled by the ‘Due in Version’ value rather than adding a new field?

You could get list of unreleased issues by creating a search that includes all tasks with ‘Due in Version’s that are in the future.

Would it be enough just to add an extra option to the ‘Due In Any Version’ dropdown called ‘Due in the Future’? I’m not sure if it would include tasks that don’t have ‘Due in Version’ set or not. I suspect it would be best to include them since tasks already released will most likely have their ‘Due in Version’ set.

Comment by Simon Large (slarge) - Wednesday, 22 June 2005, 12:46 GMT+1

That’s a very good idea.

If you do it that way can I also request that when a task is closed, if its ‘Due in version’ field is not already set, it gets set to the next release value. Otherwise we end up with a similar situation to the percent complete field where (in 0.9.7) we have to keep opening closed tasks just to update that field when someone forgets to set it before closing the issue.

Loading...