Re: Bugzilla

Re: Bugzilla

[Robert Dewar]

> The historical use of "(il)legal code" in the BTS has been "the
> compiler should (not) produce an object file from this input."
> "(In)valid" has been taken as synonymous but politically preferred,
> since no *law* is violated by buggy source code.  I think this
> encompasses both Ada's "illegal" and "erroneous", although I'm not
> sure whether all categories of "erroneous" Ada programs require
> compile-time errors.

They definitely do not, such a requirement would be hard to meet by anyone
who has not figured out how to solve the halting problem :-)

For example, it is erroneous to make a recursive call at run-time if you
have used pragma Restrictions (No_Recursion).

Indeed erroneous is reserved in Ada for those situations where it is not
practical to require compile-time errors. If a compile-time error is
required, then the program is illegal, not erroneous.

Bugzilla

[Daniel Berlin]

may go up and down the next few hours while i attempt to figure out what
is going on.

It looks like some of the actual data got very out of whack with the
mysql indexes when we ran out of space on sourceware, and while the data
is still fine, every time someone changes a bug, it seems to cause the
mysql table index files to break again :(

I'm trying some of the more "powerful" recovery options, and if that
doesn't work, i'll simply mysqldump the tables and reload them
completely.

Re: Bugzilla

[Daniel Berlin]

On Feb 6, 2004, at 2:34 PM, gcc@user.lysator.liu.se wrote:

> Hello.
>
> I think it would be nice if it was possible to attach a file to bug 
> reports
> on creation when using the bugzilla web interface.
>
> /MF

There is a bug filed for this feature on bugzilla.org.
When there are things that are supposed to be eventually fixed in the 
main bugzilla source, I generally wait till they are rather than 
reimplement them in our code, so that merges with bugzilla's mainline 
source aren't so much of a pain in the ass.

of course, if the feature never shows up in bugzilla's mainline source, 
i will eventually implement it.

Bugzilla

[gcc]

Hello.

I think it would be nice if it was possible to attach a file to bug reports
on creation when using the bugzilla web interface.

/MF

Re: Bugzilla

[Daniel Berlin]

On Tuesday, February 25, 2003, at 01:20  PM, Daniel Berlin wrote:

>
> On Tuesday, February 25, 2003, at 04:00  AM, Nathanael Nerode wrote:
>
>>>>  (Am I wrong?)  What will happen
>>>> to the exceedingly useful 'class'?
>>
>>> I can throw it into the keywords field automatically if you like, but
>>> it'll be a few days to get it right.
>>
>> That would be fine.  Some suggestions on the keyword conversion:
>>
>> * wrong-code, ice-on-legal-code, ice-on-illegal-code, rejects-legal, 
>> and
>> accepts-illegal should become keywords.  This information *needs* to 
>> be
>> kept, not dropped.
>>
> Done (They'll appear later today when i do a database update)

Done as of now, i just updated.
These are the current keywords, descriptions, and number of bugs with 
each keyword (the descriptions obviously need a bit of work).
Name					Description					Bugs
accepts-illegal 		Accepts illegal code			146
ice-on-illegal-code 	ICE on code that is not legal	470
ice-on-legal-code 		ICE on code that is legal		1293
pessimizes-code 		Pessimizes code				152
rejects-legal 		Rejects legal code				777
wrong-code 			Incorrect code				918

--Dan

Re: Bugzilla

[Daniel Berlin]

On Tuesday, February 25, 2003, at 01:37  PM, Joseph S. Myers wrote:

> On Tue, 25 Feb 2003, Daniel Berlin wrote:
>
>> It is already:
>> if (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ /^duplicate/o) 
>> {
>>        $resolution = "DUPLICATE";
>>      } elsif (defined($pr_data{"Class"}) && $pr_data{"Class"} =~
>> /^mistaken/o) {
>>        $resolution = "INVALID";
>>     ....
>
> This code is just for closed PRs?  (There are a few open PRs with Class
> (wrongly) set to "mistaken", though they could just be fixed manually
> before conversion.)
Yup, only closed PR's.
In context, it looks like:
   } elsif ($pr_data{"State"} eq "closed") {
     $bug_status = "CLOSED";
     if (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ 
/^duplicate/o) {
       $resolution = "DUPLICATE";
     } elsif (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ 
/^mistaken/o) {
       $resolution = "INVALID";
     } else {
       $resolution = "FIXED";
     }


>
> -- 
> Joseph S. Myers
> jsm28@cam.ac.uk
>

Re: Bugzilla

[Joseph S. Myers]

On Tue, 25 Feb 2003, Daniel Berlin wrote:

> It is already:
> if (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ /^duplicate/o) {
>        $resolution = "DUPLICATE";
>      } elsif (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ 
> /^mistaken/o) {
>        $resolution = "INVALID";
>     ....

This code is just for closed PRs?  (There are a few open PRs with Class
(wrongly) set to "mistaken", though they could just be fixed manually
before conversion.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Bugzilla

[Zack Weinberg]

dewar@gnat.com (Robert Dewar) writes:

>> Note that main compilers use "valid/invalid" in their diagnostics.
>> The suggestions thus mirrors practice.
>
> These terms are always tricky. In Ada legal/illegal are technical
> terms which mean precisely that syntactic and static semantic rules
> are/are not followed.  Valid (at least for programs) is not a
> techical term, and presumably would be interpreted to include the
> rejection of erroneous programs (undefined behavior in C) or
> programs with bounded errors (no analog in C).
>
> I am not objecting to the terms, just suggesting that somewhere they
> be precisely defined, and there may be language by language
> variations.

The historical use of "(il)legal code" in the BTS has been "the
compiler should (not) produce an object file from this input."
"(In)valid" has been taken as synonymous but politically preferred,
since no *law* is violated by buggy source code.  I think this
encompasses both Ada's "illegal" and "erroneous", although I'm not
sure whether all categories of "erroneous" Ada programs require
compile-time errors.

I think it would be useful to make fine distinctions in the BTS, but
in a language-neutral way -- avoiding terms of art for specific
languages and being verbose if necessary to avoid confusion.

zw

Re: Bugzilla

[Daniel Berlin]

On Tuesday, February 25, 2003, at 04:00  AM, Nathanael Nerode wrote:

>>>  (Am I wrong?)  What will happen
>>> to the exceedingly useful 'class'?
>
>> I can throw it into the keywords field automatically if you like, but
>> it'll be a few days to get it right.
>
> That would be fine.  Some suggestions on the keyword conversion:
>
> * wrong-code, ice-on-legal-code, ice-on-illegal-code, rejects-legal, 
> and
> accepts-illegal should become keywords.  This information *needs* to be
> kept, not dropped.
>
Done (They'll appear later today when i do a database update)
> * pessimizes-code should probably become a keyword too, though I couuld
> be convinced otherwise.
>
Done.

> * sw-bug should be dropped; it's the catch-all category for
> unclassified PRs.
>
Dropped.
> * duplicate should really map to whatever Bugzilla uses for duplicate
> tracking.
>
It is already:
if (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ /^duplicate/o) {
       $resolution = "DUPLICATE";
     } elsif (defined($pr_data{"Class"}) && $pr_data{"Class"} =~ 
/^mistaken/o) {
       $resolution = "INVALID";
    ....


> * doc-bug could map to a 'documentation' component, or be a keyword; 
> I'm
> not sure which would be better.
>

> * change-request should map to a severity, I believe.
>

It is already (it's mapped to severity "enhancement").

I accidently did a case sensitive grep for class when i said we ignore 
class completely.
The above cases are, however, the only previous uses until now 
(duplicate/mistaken/enhancement).

--Dan

Re: Bugzilla

[Robert Dewar]

> Note that main compilers use "valid/invalid" in their diagnostics.
> The suggestions thus mirrors practice.

These terms are always tricky. In Ada legal/illegal are technical terms which
mean precisely that syntactic and static semantic rules are/are not followed.
Valid (at least for programs) is not a techical term, and presumably would be
interpreted to include the rejection of erroneous programs (undefined behavior
in C) or programs with bounded errors (no analog in C).

I am not objecting to the terms, just suggesting that somewhere they be precisely
defined, and there may be language by language variations.

Re: Bugzilla

[Gabriel Dos Reis]

Nathanael Nerode <neroden@twcny.rr.com> writes:

| >>  (Am I wrong?)  What will happen
| >>to the exceedingly useful 'class'?
| 
| >I can throw it into the keywords field automatically if you like, but 
| >it'll be a few days to get it right. 
| 
| That would be fine.  Some suggestions on the keyword conversion:
| 
| * wrong-code, ice-on-legal-code, ice-on-illegal-code, rejects-legal, and 
| accepts-illegal should become keywords.  This information *needs* to be 
| kept, not dropped.

Nits:  Make the following substitutions

   ice-on-legal-code   => ice-on-valid-code 
   ice-on-illegal-code => ice-on-invalid-code
   rejects-legal       => rejects-valid
   accepts-illegal     => accepts-invalid

Note that main compilers use "valid/invalid" in their diagnostics.
The suggestions thus mirrors practice.

-- Gaby

Re: Bugzilla

[Nathanael Nerode]

>>  (Am I wrong?)  What will happen
>>to the exceedingly useful 'class'?

>I can throw it into the keywords field automatically if you like, but 
>it'll be a few days to get it right. 

That would be fine.  Some suggestions on the keyword conversion:

* wrong-code, ice-on-legal-code, ice-on-illegal-code, rejects-legal, and 
accepts-illegal should become keywords.  This information *needs* to be 
kept, not dropped.

* pessimizes-code should probably become a keyword too, though I couuld 
be convinced otherwise.

* sw-bug should be dropped; it's the catch-all category for 
unclassified PRs.

* duplicate should really map to whatever Bugzilla uses for duplicate 
tracking.

* doc-bug could map to a 'documentation' component, or be a keyword; I'm 
not sure which would be better.

* change-request should map to a severity, I believe.

* I have no idea about 'support' or 'mistaken', since I haven't figured 
out what they're used for.

Thanks for your hard work!

--Nathanael

Re: Bugzilla

[Daniel Berlin]

On Sunday, February 23, 2003, at 05:15  PM, Nathanael Nerode wrote:

> I'm wondering what changes are going in along with the Bugzilla
> transitions.  I don't care who's allowed to add
> components/versions/milestones, but I would like:
>
> -- Currently bugs have a 'class' and a 'category'.  I assume that 
> 'category' will become 'component'.
Yes.

>   (Am I wrong?)  What will happen
> to the exceedingly useful 'class'?
It currently gets dropped during conversion.
I'd rather not map it to severity (which is possible), since it isn't 
quite the same.
A severity of "critical" tells you something. A severity of 
"ice-on-legal-code" tells you nothing about the *severity* of the bug.

That said, one can do the same thing class used to do in nicer ways.

You could do it with keywords (which is what the mozilla guys do, 
AFAIK, and probably the best way), or use some combination of severity 
and component to say what class used to say, depending on whether the 
class was really a component (ie documentation bugs. Documentation is a 
component, thus, a class).
Adding a new dropdown field for class is possible, but i honestly think 
it would just confuse users to have a class, component, and severity.

>   Will it be preserved essentially
> as-is?  (I'd approve of that...)

I can throw it into the keywords field automatically if you like, but 
it'll be a few days to get it right.
>
> -- I'd like to get an additional 'class' added: 'warnings'.  These 
> would be 
> bugs specifically about lack of warnings, confusing warnings, mistaken
> warnings, etc.; it's a large subset of the existing 'sw-bug' bugs.  
> It's
> not really doc-bug or sw-bug, and I think it would be a very useful way
> to separate these out from other behavior bugs.
>
With keywords, you can have a bug with both at once.
The current permissions allow anyone with a gcc.gnu.org account to 
create a keyword.

> --Nathanael

Bugzilla

[Nathanael Nerode]

I'm wondering what changes are going in along with the Bugzilla 
transitions.  I don't care who's allowed to add 
components/versions/milestones, but I would like:

-- Currently bugs have a 'class' and a 'category'.  I assume that 
'category' will become 'component'.    (Am I wrong?)  What will happen 
to the exceedingly useful 'class'?  Will it be preserved essentially 
as-is?  (I'd approve of that...)

-- I'd like to get an additional 'class' added: 'warnings'.  These would be 
bugs specifically about lack of warnings, confusing warnings, mistaken 
warnings, etc.; it's a large subset of the existing 'sw-bug' bugs.  It's 
not really doc-bug or sw-bug, and I think it would be a very useful way 
to separate these out from other behavior bugs.

--Nathanael