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

Sean Kelly wrote:
> Walter Bright wrote:
>> I agree with you it's absurd. But the reality is that people can and do use bug counts as a measure of quality or progress towards quality.
> Very true.  In fact, rewards are sometimes even given to those who close the greatest number of "bug" entries per release.  Oddly, this seems to encourage developers to produce a shoddy product so they have a never-ending stream of bugs assigned to them.  It also makes no differentiation between implementing new features (difficult and productive work) vs. trivial bug fixes (easy and non-productive work), but I suppose that's what you get when non-technical people are the ones structuring the work environment.

I did see one corporation reward engineers for minimizing the bug count. What was the result? Long, knock-down drag-out fights over what was and was not a bug. Long, knock-down drag-out fights over whether bug A was one bug or really 2 bugs, or 3 bugs. And worst of all, engineers were motivated to at all costs avoid entering bugs in the database at all.

It worked for about a week until the engineers figured out how to game the system. About a month later, management realized it was a disaster and pulled it.

Yes.

(1) Its the best issue tracking system we have got working for us. It is a stable product. It can cope with the sort of functionality needed by Walter to manage issues.
(2) There are a number of things that need to be managed when developing a software product. And as it happens, the type of data and management processes are nearly identical for errors (a.k.a. bugs), enhancements, and requests for information, so a single tool that handles all these is more efficient. It takes lees time and energy to manage a single tool than multiple tools.

One can't prevent stupidity but one can demonstrate honesty. So if people use the data in an issue tracking system to make stupid conclusions there is nothing you can really do to prevent that. At best you can moderate the damage by highlighing your integrity by admitting the existance of problems and demonstating attention to them, and also showing direction with respect to requests from your clientele.

Walter, like all developers, needs tools to manage large number of issues with their products. We can see the obvious need when it comes to reported errors, but the need with requests is just as great. It is too easy to misplace adhoc requests and too easy to forget to provide feedback. A tracking system, like bugzilla, can be a useful two-way communication tool, even though it is not the one to use for discussions. We have other tools for that function - wikis and forums, for example.

-- 
Derek Parnell
Melbourne, Australia

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

While the incorrect first impression is bad, what I would be most worried about is someone who is willing to fabricate sudo-facts to make D look bad for some reason. Listing bugs with enhancement just gives them something to misquote.

In article <e6i3nf$j7l$1@digitaldaemon.com>, Lars Ivar Igesund says...
>
>
>
>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.
>
Is their any what to make it impossible to get a listing of bugs and enhancement in the same page? If the system were tweaked so the filters won't pass both at the same time (ever, even for a "all issues" count), that would make it clear that they aren't the same thing.

Don't worry about being blunt, it doesn't bother me, only lack of logic.

Brad Roberts wrote:
> On Sun, 11 Jun 2006, Bruno Medeiros wrote:
> 
>> I do agree that the NG has some disadvantages, as you pointed out, like a bit
>> of losing track of proposals, but I doubt using bugzilla would help us much
>> there.
>> I think the best way is a combination of NG discussion + wiki tracking. A wiki
>> is susceptible to vandalism, but I'm sure there ways to deal with that (not
>> even a problem right now), and other than that, I think it's a quite adequate
>> tool.
> 
> I generally avoid being this blunt, but you're totally wrong on this point.  Newsgroups and wiki are horrible at tracking open, closed, dropped, duplicate, etc state and are one of the primary reasons that issue tracking systems were invented.  Homework:  Pick a random bug report in the bugs newsgroup.  How do you determine if it's fixed.  Compare this to bugzilla.
> 

I'm not comparing that task/"homework" because that measures bugzilla's adequateness at tracking *bugs*, and not language design issues. Obviously bugzilla is great at tracking bugs, but language issues (aka language change requests) are of a quite different nature, which bugzilla is not adequate for.


>> Issue tracking is what I've been doing, albeit in an initially not very
>> sophisticated way, with my wiki entry
>> (http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D) .
> 
> So, you're going to keep track of every open issue on that page?  Good luck.  You're not?  Ok, what about the ones that you don't track?  Someone else might do the same?  Ok, so how do we find out about all these disparate places that are tracking their own favorite issues?  See, this just doesn't work at any sort of scale.  How about when issues are resolved, are you going to update your list?  How about the duplicate problem entries on the other however many people track the same issue?  It makes the problem worse not better.  Sorry.
> 

"So, you're going to keep track of every open issue on that page?"
No, I'm just keeping track of my "favorite" issues (those I thought of and discussed).

"Ok, what about the ones that you don't track?  Someone else might do the same?  Ok, so how do we find out about all these disparate places that are tracking their own favorite issues?"
We list all of them in a common page, on something similar to this http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

"See, this just doesn't work at any sort of scale."
Yes it does. Because language issues are much less frequent than implementation bugs, likely one *degree of magnitude* less frequent.

"How about when issues are resolved, are you going to update your list?  How about the duplicate problem entries on the other however many people track the same issue? "
Yes, it's quite manageable to do this manually, once again because they are many less. Do you think an issue of the likes of "reflection", "array literals" is solved every month? How many changes/enhancements did we have in D in the last year? Compare that to the number of bugs fixed...

Once again, the nature of language issues is much different than that of bugs, and the issue of tracking "open, closed, dropped, duplicate; priority" is nowhere near as important as in bugs.

I'll give some examples at the end of the post.

>> I also did recently mention interest in improving the current proposal
>> tracking situation (in
>> news://news.digitalmars.com:119/e3ae4v$2o1t$1@digitaldaemon.com ). Reposting
>> the relevant part:
>>
>> "
>> Thinking even further, the wiki could be used as a repository for summaries of
>> the current "discussion state" of design features/peeves/issues. A
>> standardized method and/or page for doing so would even be better. For
>> instance a wiki page lists the common existing design issues, and for each one
>> of those, another wiki entry exists listing a summary/abstract,
>> background(optional), issue description, points and threads argued, community
>> feedback (both negative and positive). Even if Walter doesn't pay attention to
>> it (which is expected) it helps a bit to the community to know what is the
>> current status, and the opinion of the rest of the community members.
>>
>> I know that there very standardized and very formalized processes for
>> languages changes in some other languages, and someone with knowledge of these
>> (I haven't) could contribute some good well-based ideas. We don't need nor
>> should have anything that complicated though, just something simple, which is
>> useful enough already.
>> "
> 
> I do agree with the use of the ng and various wiki's as forums for discussing enhancements, but not for tracking them.  Those discussions should point to bugzilla and vice versa.  Use whatever medium suits the people in the discussion best, but as a step toward maturing towards production, an entry in bugzilla would make it a whole lot easier to prioritize and later find information about when it comes time to ask why questions.
> 

Prioritizing is not important for language issues, it may not even make much sense. And as for finding information, that would be just as easier to do in a Wiki or Web page.

> I encourage people interested in this topic to look outside the D project at other projects to see how they deal with these very issues.  Specifically I suggest gnome, kde, mozilla, bugzilla itself, trac...
> 
> I'd actually like to see _any_ project that anyone knows about that uses a bug tracking system but doesn't use it to track new features / enhancement requests.
> 

That comparison (with other projects) is biased from the start because most other projects have much less design issues than developing a language, and much more straightforward feature requests (i.e. features that don't require much thinking/discussion about).
Even so, I will give an example in one such "biased project".
Back in the days where I cared about using Linux, I was watchful of the Gnome project (around Gnome 1.2 - 1.4, I think). Someone had an idea for an "enhancement" which consisted of reversing the order of dialog buttons ( "Ok"-"Cancel", "Yes"-"No", etc.) making them like MacOS, and the reverse of Windows. Do you think that came up in the bugzilla? No, it was much argued and discussed (OT: and I fought against it) in the gnome mailing list, but there it stayed. It made no sense to be a bugzilla entry for that. (not that there couldn't be, it just wouldn't add any usefulness)


>> tracking state:
>> The only state Bugzilla can track is whether the enhancement was implemented or not. It has no way to track, for each enhancement/issue, what is the overall opinion of the D users, how extensively was an issue discussed, the rating of each possible alternatives etc. I don't think that it is even possible to do this numerically (like voting), making a text-editing tool like Wiki more adequate.
> 
> Bugzilla can also track duplicate entries, changes over time in priority and category.  I'd argue that neither wiki nor the newsgroups can track the subjective points you suggest they can.  They both can contain the text that humans can use to re-read and come to a personal opinion about those subjective points and even record it as another opinion.  The same recording can be done in bugzilla, though keeping that sort of info in wiki and/or ng's is entirely appropriate.  Let the tools do what they're good at.  Bugzilla is good at making sure issues don't get lost due to lack of current activity.
> 

Back to the same, tracking state and priority is not that really that important for design issues.

>> categorization:
>> I disagree, the Wiki is just as good at that as Bugzilla, perhaps even better.
> 
> Maybe.. this is a rather subjective area.
> 

>> prioritization:
>> Prioritization is not an important feature for a design issue tracking.  In fact prioritization doesn't even make sense if there is no consensus, which will be the most common case.
> 
> So, there's a pile of issues and no way to tell which are more important and going to be done first, second, ... last?  Work is inherently going to be done in some order.  People working with a project want to know what expectations are reasonable to have.  Prioritization and publishing of that is a rather key aspect of a mature development process.  At some point D will grow up enough to have these needs.  I personally hope that it's there now or will get there very soon.
> 
> ================
> 
> Granted, some of this is less relevant when there's a single developer actually implementing parts, but there _are_ others that are growing in their comfort with the frontends and if D is ever going to grow to the level that other popular languages have, it's going to have to expand that base a bit.  Walter does a stellar job keeping us happy, but look at the list of peeves, wish lists, and bugs and consider where it could be with 2 or 3 other people?  David does his best to keep dgcc / gdc in sync with dmd, though it's obvious over the last 6 months that more people would be valuable on that front too.
> 
> As a parting note, let me plant these seeds:  Is D and it's community of
> developers expecting / hoping that the project(s) will grow up to
> something as large as python, ruby, java, c++?  Can it continue to survive
> with the hand tracking, scattered, random systems that are in place today?
> Is it better to establish proven development practices while still
> relatively small or after things break down?  Have they already broken
> down?  Has the lack of solid development practices held D back?
> 
> Later,
> Brad

It's good you mentioned other languages. If my arguments haven't convinced you so far, I'll give you now some proper examples (and not "biased" projects):

http://dev.perl.org/perl6/rfc/
What do we see here? This is perl's list of language issues (each called Request For Change). Does it look like bugzilla or any bug tracking system (they use perlbug)? No. It is just a HTML listing of issues, and it's a manual system (if you have a RFC, you email it, the webmaster posts it).

And also:
http://www.python.org/dev/peps/
This is Python's list of language issues (called Enhancement Proposals). Again, it's quite not a bug tracking system, it is just a web page listing. (Ok, in Python's case they are also under version control)

Why? Once again, because the nature of bugs and design issues is very different from each other. You don't even have priority rating because it doesn't makes sense.

My idea is basically to do something similar (but more lightweight) to what these language projects do for their change proposals, in the Wiki.
(Anyone interested, check http://www.python.org/dev/peps/pep-0001/ for one such process)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Brad Roberts wrote:
> 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.

Yes, and I think it's a reasonable fix. Let's see how it goes.