[Tracker-discuss] Feature/Change request handling procedure

[Brett Cannon]

On 11/21/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Martin v. Löwis wrote:
> > Stefan Seefeld schrieb:
> >> * What time scale should we expect this whole migration to take to
> >>   move forward ? Would it make sense to set up a time frame to not
> >>   let this drag on for too long ?
> >
> > I think so. Some people (GvR in particular) have been asking why
> > this isn't completed, yet.
> >
> > It would be good if it completed this year.
>
> I agree that would be good, and I think it is possible, at least
> technically.
>
> >> * I have made various fine-grained change proposals on the meta
> >>   tracker. Would it be more efficient I made an overall proposal
> >>   that allows to think in terms of the 'big picture', instead of
> >>   piece meal changes ?
> >
> > I think people won't respond at all to tracker schema changes,
> > no matter how much feedback you request. Instead, they want to
> > see the complete solution, life.
> >
> >> * What exactly do we need in order to consider a change to be
> >>   approved ?
> >
> > The tracker team can do whatever they want, IMO. The infrastructure
> > committee should back them up and support them as long as we had a
> > chance to comment.
>
> OK, fair enough. So, let me present a little hand-drawn schema I'm aiming
> for, with some comments. The goal is to allow users to report bugs with
> as much detail as possible, without getting into their way. All properties
> are typed (i.e. use links to predefined entities), instead of simple
> strings,
> to avoid typos and make querying easier.
>
> Roundup's permission handling, together with auditors, should help us
> keeping the workflow / bug lifetime streamlined, i.e. make it obvious to
> everybody what the potential state transitions are.
>
>
> Schema
> ------
>
> bug = (title,
>        messages,
>        files,
>        type,
>        components,
>        platforms,
>        version,
>        severity,
>        dependencies,
>        status,
>        resolution,
>        superseder)
>
> pep = (title, messages, files, ...)
>
> milestone = (name, messages, eta, bugs, peps)
>
>
> Comments:
>
> * type is an enum helping to classify the bug. For example:
>   (crash, compile error, resource usage, security, rendering, behavior,
> rfe)
>
> * components expresses what parts are affected
>
> * platforms expresses what platforms are affected
>
> * 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.

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.

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

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

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

Developers set assignee, status, resolution, dependencies, and superseder.
>
> Conversion
> ----------
>
> Conversion from 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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061121/afecb275/attachment-0001.htm