[Tracker-discuss] Feature/Change request handling procedure

[Erik Forsberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

Sorry for being late with comments - it's been a _veery_ busy week.

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

This is all good. 
>
> bug = (title,
>        messages,
>        files,
>        type,
>        components,
>        platforms,
>        version,
>        severity,
>        dependencies,
>        status,
>        resolution,
>        superseder)

I know there has been discussions back and forth about the naming of
the main database type - "bug" or "issue" or something else. 

Personally, my opinion is that it should not be "bug", because one
might also want to enter feature requests (which are not bugs) and
other kinds of "issues", which takes us back to "issue" which is a
nice and general name. OTOH, I guess the Python project handles its
feature requests mostly by PEPs, so perhaps everything entered into
this database will actually be bugs?

I don't think the name of the class matters that much, though. At my
work, we use a bugzilla instance for tracking both bugs and feature
requests, and it confuses our sales people at least once a month :).

> pep = (title, messages, files, ...)
>
> milestone = (name, messages, eta, bugs, peps)

I don't see the milestones in the current test tracker? 

I think it's important to be able to add a reference to the intended
milestone(s) from the bug, not the opposite. Perhaps there should be a
Link(milestone) or Multilink(milestone) on bug instead of a
Multilink(bug) on milestone?

I don't know how the decisions on which bugs should be part of which
releases are made - perhaps one of the release managers could give a
hint on how this should work to make the process easy? 

Btw, perhaps we could use milestones for keeping track of bugs that
need to be backported? If a bug could belong to several milestones
(and be open/closed in several milestones), it could first be closed
on the milestone for the next big release, then be closed on the
milestone for a backport release. 

This also depends on how the Python release process works, and I don't
know much about it, so some feedback would be appreciated. Also, I
don't know if it's currently possible to design such a solution with
roundup. Just a wild idea :)

> * status: one of (new, open, closed)
>
> * resolution, set when status is set to closed: one of (fixed, invalid, duplicate)

I like this. It's very much how Bugzilla does it, and I like how
Bugzilla does it. We might consider a different UI than select boxes -
Bugzilla uses radio buttons, for example "close bug, mark as duplicate
of <superseder>"

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFaLd5rJurFAusidkRAgLEAKDNKDvEEHwI7TLeD15d6ZoerEvDwQCfQxE5
RHszzQU9v29PUEu+ChuJ9PA=
=7eGB
-----END PGP SIGNATURE-----