Some feedback now that I've used this a bit:

How should documentation bugs be filed?  Using the "www.digitalmars.com" component?  Or perhaps a separate component should be created for this?

After clicking "new" to enter a new bug, the list of targets includes "TestProduct," which should be removed.

It would be nice to establish some submission guidelines, particularly on how to set priority and severity.

Establishing general criteria for keywords might be useful as well. I'll enter them, but don't know what search terms to use.

Would Walter prefer test cases entered in the description or attached as files?  I've done the former for old bugs, but it would be useful to know how to format future reports.

That's it for now.  More as I think of it :-)


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:dufhan$uj9$1@digitaldaemon.com...
> It would be nice to establish some submission guidelines, particularly on how to set priority and severity.

Priority:

P1: so bad that an update needs to happen immediately; i.e. it makes D
unusable
P2: fold into next update; things that break existing code go here
P3: should get around to fixing sooner or later
P4: defer until next major version
P5: informational; nobody really cares

Severity:

blocker - prevents use of a major component of D, such as phobos
critical - silent generation of bad code
major - produces compiler crash or generation of internal error messages
normal - garden variety bugs
minor - easy workaround
trivial - only of interest to compiler validation test suites
enhancement - change to documented behavior

> Would Walter prefer test cases entered in the description or attached as files?  I've done the former for old bugs, but it would be useful to know how to format future reports.

If the size is reasonably small, they should be in the description.

On Sun, 5 Mar 2006, Walter Bright wrote:

> Priority:
> 
> P1: so bad that an update needs to happen immediately; i.e. it makes D
> unusable
> P2: fold into next update; things that break existing code go here
> P3: should get around to fixing sooner or later
> P4: defer until next major version
> P5: informational; nobody really cares

I'll add these to the page you see when you click on the Priority link when entering a bug.  I tend to think of priority as something that you as the author should be setting.

> Severity:
> 
> blocker - prevents use of a major component of D, such as phobos
> critical - silent generation of bad code
> major - produces compiler crash or generation of internal error messages
> normal - garden variety bugs
> minor - easy workaround
> trivial - only of interest to compiler validation test suites
> enhancement - change to documented behavior

I tend to think of severity as something the submitter sets, though it can be adjusted certainly.

IMHO, Severity should be tempered by the nature of the bug.  If it's a crash of the compiler on invalid code that is less severe than a crash on valid code.

Some of your descriptions above touch on another area of classification that fits into what bugzilla calls keywords. I've copied the same keywords that the gcc crew use.  Click on the keywords link when submitting a bug to see the list.

I can update the docs to list the above descriptions, but before I do, here's the current descriptions.  Think a little about this before I go and change them.

Blocker     Blocks development and/or testing work
Critical    crashes, loss of data, severe memory leak
Major       major loss of function
Minor       minor loss of function, or other problem where easy workaround is present
Trivial     cosmetic problem like misspelled words or misaligned text
Enhancement Request for enhancement

> > Would Walter prefer test cases entered in the description or attached as files?  I've done the former for old bugs, but it would be useful to know how to format future reports.
> 
> If the size is reasonably small, they should be in the description.

If the test case is small and unlikely to change, I agree.  If you think the test case is going to evolve, an attachment is probably better since they can be marked obsolete making it easier to track the relevance of them.

Later,
Brad

"Brad Roberts" <braddr@puremagic.com> wrote in message news:Pine.LNX.4.64.0603051503050.30259@bellevue.puremagic.com...
> I can update the docs to list the above descriptions, but before I do, here's the current descriptions.  Think a little about this before I go and change them.
>
> Blocker     Blocks development and/or testing work
> Critical    crashes, loss of data, severe memory leak
> Major       major loss of function
> Minor       minor loss of function, or other problem where easy workaround
> is present
> Trivial     cosmetic problem like misspelled words or misaligned text
> Enhancement Request for enhancement

These look good. Don't change them. I had thought there were no guidelines.

Brad Roberts wrote:
> On Sun, 5 Mar 2006, Walter Bright wrote:
> 
>> Priority:
>>
>> P1: so bad that an update needs to happen immediately; i.e. it makes D unusable
>> P2: fold into next update; things that break existing code go here
>> P3: should get around to fixing sooner or later
>> P4: defer until next major version
>> P5: informational; nobody really cares
> 
> I'll add these to the page you see when you click on the Priority link when entering a bug.  I tend to think of priority as something that you as the author should be setting.

Same here.  But it's helpful if the submitter can make a reasonable guess at categorizing things--I know that I tend to push off bug reports with blank priority info and the like until I find time to review them... and it's rare that I find that time.  A perfect design may be more workflow-oriented, so the recipient could have an inbox of sorts where new bugs appear.  Though perhaps there's an easy way to manage this with reports?  I'll have to play with Bugzilla a bit more and see.

>> Severity:
>>
>> blocker - prevents use of a major component of D, such as phobos
>> critical - silent generation of bad code
>> major - produces compiler crash or generation of internal error messages
>> normal - garden variety bugs
>> minor - easy workaround
>> trivial - only of interest to compiler validation test suites
>> enhancement - change to documented behavior
> 
> I tend to think of severity as something the submitter sets, though it can be adjusted certainly.
> 
> IMHO, Severity should be tempered by the nature of the bug.  If it's a crash of the compiler on invalid code that is less severe than a crash on valid code.

Aye.  I was mostly trying to make sure that the existing values were meaningful to the recipient.  No reason to use the defaults if an alternate definition would be more fitting.

> Some of your descriptions above touch on another area of classification that fits into what bugzilla calls keywords. I've copied the same keywords that the gcc crew use.  Click on the keywords link when submitting a bug to see the list.

Thanks.  I'll give it a look.


Sean

Brad Roberts wrote:
> Ok.. it's probably a little rough still, but I think it's usable now.  I've got bugzilla setup here:
> 
>     http://d.puremagic.com/bugzilla/
<snip>

Good idea.  Just a few preliminary nitpicks:

- On the product list: "The DigitalMars D compiler and it's various components"
s/it's/its

- There ought to be a "d.puremagic.com" product, similar to the "mozilla.org" component in bugzilla.mozilla.org, for reporting issues with the Bugzilla installation (configuration issues, requests for new components/keywords, etc.).

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Brad Roberts wrote:
> Ok.. it's probably a little rough still, but I think it's usable now.  I've got bugzilla setup here:
> 
>     http://d.puremagic.com/bugzilla/

"Bugzilla would like to put a random quip here, but no one has entered any."

That's because submission of new quips is disabled.  What's this about?  Either enable submissions or remove the quip display.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Mon, 6 Mar 2006, Stewart Gordon wrote:

> Brad Roberts wrote:
> > Ok.. it's probably a little rough still, but I think it's usable now.  I've got bugzilla setup here:
> > 
> >     http://d.puremagic.com/bugzilla/
> <snip>
> 
> Good idea.  Just a few preliminary nitpicks:
> 
> - On the product list: "The DigitalMars D compiler and it's various
> components"
> s/it's/its

Fixed.

> - There ought to be a "d.puremagic.com" product, similar to the "mozilla.org" component in bugzilla.mozilla.org, for reporting issues with the Bugzilla installation (configuration issues, requests for new components/keywords, etc.).

Good idea, added.

Later,
Brad

On Mon, 6 Mar 2006, Stewart Gordon wrote:

> Brad Roberts wrote:
> > Ok.. it's probably a little rough still, but I think it's usable now.  I've got bugzilla setup here:
> > 
> >     http://d.puremagic.com/bugzilla/
> 
> "Bugzilla would like to put a random quip here, but no one has entered any."
> 
> That's because submission of new quips is disabled.  What's this about? Either enable submissions or remove the quip display.

Enabled as moderated for now. If the submissions stay clean and reasonable, I'll probably open it up.  I don't like cleaning up after abuse, so I'd rather keep it simple and make sure it doesn't get abused.

Later,
Brad

Adding or changing features in the D language involves changing both the compiler and specification.  As such, should such requests be filed under DMD or under www.digitalmars.com?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.