[Tracker-discuss] Feature/Change request handling procedure

[Erik Forsberg]

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

Stefan Seefeld <seefeld at sympatico.ca> writes:

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

Hmm.. I have a feeling that you misunderstand what I'm trying to say. 

I fully agree that you should be able to turn a feature request into a
bug very easily, and that is exactly why I think the main class should
not be named "bug". I don't want another class for feature requests, I
want the main class to cover as many types of issues (see, there it is
again, the perfect word for it! :) as possible. 

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

Actually, I don't think it matters that much which of the two classes
in the relation has the actual link property, as long as it's easy to
set a link from the bug display. 

At work, where we use bugzilla, we use milestones a lot. Typically,
during a week, a bunch of new bugs are found. They are entered into
bugzilla and the milestone is then set to '--' which is bugzillaish
for "not yet decided". During our weekly development meeting, we then
iterate through the bugs with milestone "--" and set the milestone to
something more appropriate such as "release X.Y". 

If we would first have to find the bug, then locate the milestone and
add the bug there, it would be much less convenient. 

The above provided as an example of why I think being able to set
milestones from the bug display is important. The python-dev people
might use a completely different procedure (some kind of Silly Walk,
perhaps? :)  )

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

Yup.

Implementing this might need some kind of "Link with a property"
property-type in roundup. We want to store not only a link from the
milestone to the issue (or from the issue to the milestone ;-) ), but
also the status (open/closed/...). That is currently not possible as
far as I understand - I asked about this a while ago in this thread:

http://permalink.gmane.org/gmane.comp.bug-tracking.roundup.user/6890

Perhaps there are ways to do this without this kind of link type? 

> (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.)
You must call it AJAX, or the Web 2.0-meter will not react :-). 

Cheers,
\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/>

iD8DBQFFaMrWrJurFAusidkRAkk1AJ9bt22Fxd2kp6Ul6d5kGNN9hUz8lACfZD4d
8L2bfwqqUnR81Of+AUcYvAk=
=cmwz
-----END PGP SIGNATURE-----