Should enhancement requests be allowed in bugzilla?

[Brad Roberts]

On Sun, 11 Jun 2006, Lars Ivar Igesund wrote:

> Walter Bright wrote:
> 
> > People are always going to take shortcuts to understanding something.
> > When something labeled as a BUG database is filled with enhancement
> > suggestions, they will be perceived as bugs - not by you or me, but by
> > people taking a quick first look at D. Trying to counter that first
> > impression will consume a lot of our energy we can ill afford to expend.
> > It's a lot easier to give a correct first impression than to try to
> > counter a false one. Listing enhancement requests in a bug database
> > gives a bad first impression.
> 
> You have previously worked on commercial projects, where any sort of public
> information on the quality of the product might have been difficult to get
> by.

I've worked on both opened and (more often) closed source commercial 
projects.  In every one of them, the same system was used for tracking 
bugs and issues, so I'm biased by experience.  The only place I've seen 
two systems used for tracking issues is where one was used for operational 
problems (auto-cut tickets be it hardware failures, unexpected system 
latencies, manifestations of bugs,etc) and another used for longer term 
bug tracking and feature management.  Even in that environemnt, the main 
reason for not moving the auto-cuts into the same system as used for issue 
tracking was more due to legacy and pain of re-configuring hundreds of 
systems than anything else (both on the ticket creation side as well as 
the reporting and messaging of the events associated with the tickets).

> D is very much unlike these projects, and is per your own wishes an open
> project. And all commercial corporation today need to take into themselves
> that a large number of viable and important software projects are open, and
> they support them, even if they like KDE have 12000 open bug reports and
> 10000 open wishes, numbers posted and commented on weekly, with bug closing
> stats, and new bugs stats.
> 
> In the open source software world, bugzilla is known for holding both bugs
> and enhancements request, and if some commercial entity decides not to use
> D, it is because it is an open project (because someone still thinks that
> is a sign of low quality). If they are open to open projects, they already
> know that a bugzilla also usually contains enhancements.

Well said. :)

The only real comment I have is that D isn't different in that it's open 
vs closed source, since in some important ways it still is closed source, 
but more that it's controlled by a single person at least from a primary 
compiler and language definition standpoint.  That does change the game a 
bit in comparison to most other projects.

> We need the right tool to track what happens, and currently bugzilla is the
> only alternative (and considering other projects, seriously successful at
> that!) Several enhancements posts to the bugzilla shows that people expect
> it to handle such. And as OpenOffice.org call their bugzilla IssueZilla, I
> suspect that a similar change would be possible here.

Only is too strong a word, there are definitly others.  Bugzilla is the 
one I have the most experience with and debatably is one of the best known 
systems so it's what I setup.  Some other notable examples: trac, jira, 
gnats, fogbugz, eventum.

As an experiment, I took 15 minutes or so to find and change the 
bugzilla templates to use 'issue' throughout a high percentage of the 
instances (there's a simple config variable for it).  Additionally, I've 
added a symlink so that it can be accessed as:

   http://d.puremagic.com/issues/ as well as
   http://d.puremagic.com/bugzilla/

Obviously this isn't a 100% obliteration of the term 'bug' from any usage 
all over.  There's cgi's that would need to be renamed, form parameters 
passed in url's, etc.  It's still a useful experiment, I think.

Later,
Brad