FYI, here's a quick review of the bug workflow we want to be using. It
was brought to my attention that we have a number of bugs marked as
fixed in 1.1, even though 1.1 and RC3 are currently identical code and
many of those bugs were marked resolved some time ago.
1. Reported bugs should be associated with a release in which they can
be reproduced. Please don't set a target release unless you're
committing to work on it yourself before that release. If you think
something needs to be prioritized, bring it to our attention on the
mailing list or on IRC.
2. The target release should generally remain unset unless it seems like
a bug "really" needs to be in a given release. This would include bugs
that seem like critical compatibility blockers. Note: We will move bugs
from release to release to match what available resources we have to
work on them.
3. Once the bug is fixed or determined to have been fixed already, the
target release should be re-set to the release in which it will be or
has been delivered to the world. So if a bug is marked to be fixed "by
1.1" and at some point it gets fixed as a result of other changes, the
target fix release should be whatever the upcoming release is (possible
one of the RCs. Under no circumstances should a bug be marked resolved
against a release more than two in the future.
4. Bugs should not be closed until the release in which they are fixed
has been officially delivered. Generally Tom or I will handle a bulk
close of such issues.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
