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