[Tracker-discuss] Feature/Change request handling procedure

[Stefan Seefeld]

Erik Forsberg wrote:

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

Well, I thought we would eventually handle PEPs, too !
And I also suggested 'milestone' (which isn't yet part of the current
live schema, but can be added simply and non-intrusively).

So, these three would all be 'issues' in the general sense that roundup
is an 'issue tracker'.

Finally, I don't agree that 'feature requests are not bugs'. The formal
handling of PEPs aside, I believe there is a blurry line, where some
bugs may turn into feature requests ('add better documentation' or
'complete this API'), so it is good to be able to turn one into the
other by a simple change of an enumerator.

But, may be this is really up to the people who will actually deal
with these issues to decide whether they want it that way or the other.

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

Heh, just provide some filters so they only see what they want to see.

>>> pep = (title, messages, files, ...)
>>>
>>> milestone = (name, messages, eta, bugs, peps)
> 
> I don't see the milestones in the current test tracker? 

Correct.

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

Hmm, I don't agree that 'fixed for milestone X.Y' should be a property
of a bug. On the other hand, I can easily see it to be convenient to
assign due dates or somesuch from the bug's display. But that is just
a matter of adding the relevant logic to the bug.item.html template
(and may be to the bug.search.html template, too).

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

That's an interesting point. Milestones are mostly associated with
particular branches, while bugs (at least in my suggested schema)
could be associated with multiple versions / branches. Isn't that
an argument in favor of putting the link between bug and milestone
into the milestone, not the bug ? :-)

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

Yeah, I agree. "It's just a matter of coding" is certainly true, in particular
with the wonderful roundup design. However, more feedback from the python-dev
people would be useful to decide how to proceed.

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

Interesting idea. Yeah, the GUI could certainly be made more convenient to use.
(For example some javascript to only enable the resolution field if status is
being set to 'closed', or somesuch to better guide the user through the form.)

Thanks for the feedback !

		Stefan

-- 

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