Give me a break

[Don]

Walter Bright wrote:
> yigal chripun wrote:
>> Lars T. Kyllingstad Wrote:
>>
>>> yigal chripun wrote:
>>>> Either you need to have a plan or you need to have a community
>>>> driven process (Java JSRs, Python PEPs).
>>> There is a similar option for D, although it doesn't have a fancy 
>>> abbreviation: You can put enhancement requests in Bugzilla and get
>>>  people to vote for them.
>>>
>>> -Lars
>>
>> you must be kidding right? maybe the situation is improving lately
>> but not that long ago I remember posts by downs where he pointed out
>> an old bug in DMD with a patch to fix that bug already in Bugzilla
>> and that fix was in bugzila several *years* without anyone caring.
> 
> If that is the bug I am thinking of, the patch papered over one instance 
> of the problem and didn't fix it at all. The patch even noted that it 
> was incomplete. The real fix required much more extensive work, and 
> there were higher priority problems.
> 
> My general experience with posted compiler patches is about half of them 
> are good, the other half are incorrect and require more development.
> 
> For a more recent example, 3122 contained a patch that was marked as 
> complete and tested, but it had two serious bugs (did not check that a 
> filename was supplied, and did not check for file write errors) and an 
> unnecessary hardcoded OS dependency (on path lengths). These aren't hard 
> to fix, and I merged in the patch with fixes, I'm just trying to say 
> that things are not as simple as just apply patches.
> 
> That said, I still appreciate and encourage posting patches to bugzilla, 
> as even if incomplete they still cut down the work for me that is 
> necessary to fix the problem, and hence they are valuable.

It'd be good to have a keyword in bugzilla, "patch-rejected", which you 
could use if there's a problem with a patch and you aren't going to 
include it in the next release. Then, such cases wouldn't keep showing 
up on a search for all 'patch' bugs, and patch contributers could check 
for them, redoing their patch if desired.

Another useful keyword would be "no-line-number". Error messages with no 
line number are high severity (almost as important as compiler crashes), 
but they're hard to track right now.

This would give the bug severity list as:

patch
wrong-code
ice-on-valid-code
ice-on-invalid-code
no-line-number
rejects-valid
accepts-invalid
diagnostic

Currently, 'patch' is one of the biggest categories in bugzilla! <g>.