FWIW I added a 'Due Date' to our tracker by following the example in the Roundup guide. However, I decided not to use an actual date field but rather strings, so that you can have due dates like "v2.6", "ASAP", and "2Q 2007"; the problem with real dates was that releases do not tend to have stable dates. Using the ordering attribute you can control the order of the groups in a custom search by due date. I added a permission class to give to those special managers allowed to create new 'due dates'.
<br><br>As I mentioned before we use a special priority to indicate things that have been fixed but are not yet in the main line; but perhaps in the Python context that would be irrelevant. A due date can indicate when the fix or enhancement will appear.
<br><br><div><span class="gmail_quote">On 11/15/06, <b class="gmail_sendername">Georg Brandl</b> <<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Stefan Seefeld schrieb:<br>> Anthony Baxter wrote:<br>>> Speaking for myself - we use priorities to mark "stuff which needs<br>>> to be looked at before release X.Y" and the like. This could, and<br>
>> should, be better implemented using keywords.<br>><br>> What's the advantage of using keywords for this instead of a more<br>> structured approach where the bug either has a property of type<br>> 'target version', or where there is another entity 'release' or 'milestone'
<br>> that refers to all bugs to be closed ?<br>> The latter has the advantage of being more expressive, so you could<br>> form more complex queries more easily (either online, or when<br>> generating reports, etc.).
<br><br>The milestone concept is already weakly used with the SourceForge groups.<br>IMO it's a good concept, helps you keep track of which bugs should be closed<br>before which release. Together with a priority/type classification (showstopper,
<br>major bug, minor bug, nuisance, enhancement request), there might be a better<br>possibility to establish guidelines on which bugs must be looked at before<br>release.<br><br>regards,<br>Georg<br>_______________________________________________
<br>Tracker-discuss mailing list<br><a href="mailto:Tracker-discuss@python.org">Tracker-discuss@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/tracker-discuss">http://mail.python.org/mailman/listinfo/tracker-discuss
</a><br></blockquote></div><br>