[Tracker-discuss] Feature/Change request handling procedure

[Stefan Seefeld]

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) ?

> 
>     * 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. :-)

>     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.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...