<br><br><div><span class="gmail_quote">On 11/21/06, <b class="gmail_sendername">Stefan Seefeld</b> <<a href="mailto:seefeld@sympatico.ca">seefeld@sympatico.ca</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;">
Brett Cannon wrote:<br><br>> * version is an enum to express the python version (or branch) the<br>> problem<br>> occured in.<br>><br>><br>> Is this a single setting, or can it have multiple values? If we
<br>> automatically close old bugs, it might get us to deal with things faster<br>> and thus we won't have bugs from a couple versions back. But otherwise<br>> we can end up with bugs where they are present in 2.3
and people need an<br>> easy way to note that it is still present in 2.5, etc.<br><br>Good point. It certainly can be a multilink, i.e. refer to multiple<br>versions / branches. (An interesting side-note: if we hook up with
<br>subversion, we probably want to track changes to individual branches<br>and only close out the parts of a bug that got affected by a checkin.)<br><br>> This also brings up the idea of having a dependency field. If I am
<br>> waiting for feedback or more details from someone, set that field to<br>> their username. If I don't here from them after a set amount of time<br>> (like two weeks) the bug gets closed automatically for lack of information.
<br><br>Right. I think there can be a status enumerator for this state, together<br>with a timer that gets started whenever that state is entered.<br><br>><br>> * severity is an enum allowing users to express the impact the bug
<br>> has on them,<br>> such as: (critical, major, normal, minor)<br>><br>> * dependencies: a list of bugs that need to be fixed before this can<br>> be fixed.<br>><br>> * status: one of (new, open, closed)
<br>><br>> * resolution, set when status is set to closed: one of (fixed,<br>> invalid, duplicate)<br>><br>><br>> Also add "Lack of Info" or something since we end up with bugs that just
<br>> sit there waiting for more info from the OP that we never get.<br><br>Good point. Wouldn't that be the same status enumerator as above<br>(or at least, very similar) ?</blockquote><div><br>Yes. I put it in just in case the previous idea didn't work.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> * superseder: a follow-up bug, if resolution is set to duplicate.
<br>><br>> * milestone is an issue type useful for release management. With it<br>> it is<br>> possible to query for bugs / peps to be closed for a given point<br>> (release / time)<br>>
<br>><br>> So like showstopper, A1, B2, etc.? That way one can specify that this<br>> bug must be closed by that point or else the release is blocked?<br><br>Right. However, that would be an attribute of the milestone -> bugs link,
<br>not the bug itself. The bug itself doesn't care that a milestone is on hold<br>for it. :-)<br><br>> * pep is a placeholder for PEPs, just to illustrate that this<br>> tracker can grow. :-)<br>><br>>
<br>> =)<br>><br>> Access<br>> ------<br>><br>> Users submit bugs, setting title, and optionally components,<br>> platforms, version,<br>> and severity.<br>><br>><br>> Don't let them set severity. I have gotten into mini competitions with
<br>> OPs over resetting the severity. They think they know better than me<br>> what is severe and what isn't. And everyone's bug to them is severe. =)<br><br>I guess that's your call. I have made good experience with such a flag.
<br>And, it doesn't have to affect your ranking, it's merely a hint, you know. :-)</blockquote><div><br>Right, but bug reporter's take it seriously and can get angry if you don't give it a priority that they agree with, and thus take it upon themselves to change.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Developers set assignee, status, resolution, dependencies, and<br>> superseder.
<br>><br>> Conversion<br>> ----------<br>><br>> Conversion from <a href="http://sf.net">sf.net</a> <<a href="http://sf.net">http://sf.net</a>> should map 'category' to<br>> 'components',
<br>> and 'group' to 'version'.<br>><br>><br>><br>> If there are no objections, I'm going to start to implement it.<br>><br>> Comments ?<br>><br>><br>> Any way to flag that a patch might be ripe for backporting? Sometimes
<br>> people fix stuff in svn but don't have the time or inclination to<br>> backport, so it can get lost (people are supposed to note it in<br>> Misc/NEWS, but that is really the wrong place to denote it). If there
<br>> was a way to close a bug and flag it as needs backporting (or have a<br>> "Backport" resolution) that would help matters.<br><br>That sounds like something for for a roundup script, where a new bug<br>
is created by cloning an old one, but attached to a different branch / version.<br>Or somesuch.</blockquote><div><br>Maybe. I just want the feature. =)<br><br>-Brett<br><br> <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks,<br> Stefan<br><br>--<br><br> ...ich hab' noch einen Koffer in Berlin...<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>