[Tracker-discuss] Feature/Change request handling procedure

Brett Cannon 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
> information.
>
> 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
> hold
> 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
change.

>     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 /
> version.
> Or somesuch.


Maybe.  I just want the feature.  =)

-Brett



Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061122/f121ab83/attachment.htm 


More information about the Tracker-discuss mailing list