Derek Parnell Wrote:

> On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:
> 
> > The order of importance of bugs is roughly:
> > 
> > 1. silently generating bad code
> > 2. compiler crashes
> > 3. regressions that break previously working code
> > 4. not accepting valid code
> > 5. accepting invalid code
> > 6. poor error messages
> > 
> > Throw into that how much work a bug is to fix, how many projects it affects, if there's a patch submitted, etc.
> 
> This is useful and important information. IMO it should be on your website ASAP.
> 
> I think you have forgotten another criteria that should be on this list, the age of a bug report. Although a bug, which doesn't fall into the top priorities here, is old it does not mean that it shouldn't be looked at. From a product perspective you are correct - it is of low importance, but from a client perspective, submitting a bug report which is effectively placed in limbo is a let down - it can cause people to no longer want to help you.
> 
> A trickle of older bugs being fixed would do wonders for client relationship management - especially those with higher votes.
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> skype: derek.j.parnell

A few other metrics that effect user perception
1. Has the assignee ever commented on the bug?
2. When will the bug be fixed? Has a milestone been assigned?

On Tue, 12 May 2009 13:57:09 -0700, Walter Bright wrote:

> Christopher Wright wrote:
>> Awesome! I'll add this to wiki4d. Might I also suggest adding it to some reasonable location on digitalmars.com and bugzilla?
> 
> I think the wiki is the best place.

But the wiki is not authoritative, only your web site is with respect to D matters.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Walter Bright Wrote:

> Jarrett Billingsley wrote:
> > You can't honestly expect people to submit patches if you're not going to give feedback as to why you won't include them!
> 
> Quite a lot of the submitted patches have been incorporated.
> 
> The patch report itself says it's incomplete.

It's very easy to imagine people making patches to show how they think an issue should be fixed without knowing enough to truly say it's right. A few words of encouragement to partial patchers may get them to polish it. If the last comment on a bug report is you saying the assignee saying the patch is too incomplete for inclusion with tips or a link to patch submission guidelines, then nobody will complain that the core D developers ignored them or a perfectly good patch...

Walter Bright wrote:
> Christopher Wright wrote:
>> Awesome! I'll add this to wiki4d. Might I also suggest adding it to some reasonable location on digitalmars.com and bugzilla?
> 
> I think the wiki is the best place.
> 
>> What do you do about examples that should explicitly not compile? For example, a test for the fix to an accepts-invalid bug? Do you have to use tricks with __traits(compiles) and static assert (!is (typeof))?
> 
> I'd eventually like to go that route, but currently it is a long list of files that are compiled one by one and tested to see if the compilation return a non-zero exit status.

Okay, so you have two classes of test cases: those which should compile, run, and exit(0); and those which should not compile.

== Quote from Jason House (jason.james.house@gmail.com)'s article
> Derek Parnell Wrote:
> > On Tue, 12 May 2009 10:13:38 -0700, Walter Bright wrote:
> >
> > > The order of importance of bugs is roughly:
> > >
> > > 1. silently generating bad code
> > > 2. compiler crashes
> > > 3. regressions that break previously working code
> > > 4. not accepting valid code
> > > 5. accepting invalid code
> > > 6. poor error messages
> > >
> > > Throw into that how much work a bug is to fix, how many projects it affects, if there's a patch submitted, etc.
> >
> > This is useful and important information. IMO it should be on your website ASAP.
> >
> > I think you have forgotten another criteria that should be on this list, the age of a bug report. Although a bug, which doesn't fall into the top priorities here, is old it does not mean that it shouldn't be looked at. From a product perspective you are correct - it is of low importance, but from a client perspective, submitting a bug report which is effectively placed in limbo is a let down - it can cause people to no longer want to help you.
> >
> > A trickle of older bugs being fixed would do wonders for client relationship management - especially those with higher votes.
> >
> > --
> > Derek Parnell
> > Melbourne, Australia
> > skype: derek.j.parnell
> A few other metrics that effect user perception
> 1. Has the assignee ever commented on the bug?
> 2. When will the bug be fixed? Has a milestone been assigned?

One thing I would add to prioritizing bug fixes is how many other bugs the feature has.  Features that are severely buggy, such as array ops or alias this benefit relatively little from having a single bug fixed because anyone using those features still has to constantly remember that they're buggy and keep the workarounds in mind anyhow.  Furthermore, bugs often overlap in how they limit functionality in real-world use cases.

On the other hand, features that are pretty well debugged, but still have a few little gotchas, like variadic templates and auto return (See bug 2251 --you can't use both at the same time) or ddoc benefit much more from a single bug fix.  Once these last few remaining issues are solved, these features can be used as "gotcha-free" and the user need not constantly feel like he/she is walking through a minefield when using them.

On Wed, 13 May 2009, dsimcha wrote:

> One thing I would add to prioritizing bug fixes is how many other bugs the feature has.  Features that are severely buggy, such as array ops or alias this benefit relatively little from having a single bug fixed because anyone using those features still has to constantly remember that they're buggy and keep the workarounds in mind anyhow.  Furthermore, bugs often overlap in how they limit functionality in real-world use cases.
> 
> On the other hand, features that are pretty well debugged, but still have a few little gotchas, like variadic templates and auto return (See bug 2251 --you can't use both at the same time) or ddoc benefit much more from a single bug fix.  Once these last few remaining issues are solved, these features can be used as "gotcha-free" and the user need not constantly feel like he/she is walking through a minefield when using them.

To counter that a little, a few fixes all in one area are a great way to get a lot of bang for the buck.  Less time spent due to already being in the right area of the code, and a potentially huge benefit from polishing a feature into being really usable.

Just shows how seldom there's an obviously right path to choose.

Later,
Brad

Walter Bright wrote:
> Jarrett Billingsley wrote:
>> I know.  How many months has bug 314* had the most votes?  And 313
>> while we're at it.  Importing has been broken for years and instead D2
>> is getting thread-local variables.  It seems like a gross misdirection
>> of effort.
> 
> 314 does not affect correct code, hence is an implicitly less important issue.
> 
> The order of importance of bugs is roughly:
> 
> 1. silently generating bad code
> 2. compiler crashes
> 3. regressions that break previously working code
> 4. not accepting valid code
> 5. accepting invalid code
> 6. poor error messages
> 
> Throw into that how much work a bug is to fix, how many projects it affects, if there's a patch submitted, etc.

Out of the blue, this gives a thought:

Suppose you (Walter) encounter a bug report in bugzilla, and decide to not fix it right now.

It would probably be very informative, and crowd-pacifying, to simply write two lines of text, describing why you *this time* want to prefer other things.

Then (like 2months to 3years later), when you stumble upon the same BR, you might rewrite the "motivation of a not-now fix".


The people who read the items, have an easier time accepting the omission of a bug fix, if there's a hint of motivation there.

---------------------------

Sorry for asking, but is this somewhere in the path a newbie (or a semi-newbie who's frustrated) stumbles upon it:

>
> The order of importance of bugs is roughly:
>
> 1. silently generating bad code
> 2. compiler crashes
> 3. regressions that break previously working code
> 4. not accepting valid code
> 5. accepting invalid code
> 6. poor error messages
>

(I mean, this post instance in this particular newsgroup should not be the only place where that list is "encounterable".)

Walter Bright wrote:
> Robert Clipsham wrote:
>> Walter Bright wrote:
>>> 314 does not affect correct code, hence is an implicitly less important issue.
>>
>> It does however include a patch, submitted almost a year ago I might add.
> 
> Yes, but the patch is incomplete.

At the time I'm reading this, I see in the thread window that Cristian and Jarrett have already answered this particular post.

However, I take such an offence that I (against my normal behavior) post a reply here before even bothering to read theirs first.



If you consider a patch incomplete, wouldn't it be more appropriate to address the issue, than waiting (days, years??) before you get put back-to-wall about it???

Just posting what's wrong or missing with the patch right away would catch the patch poster _while_ he's _still_ got it in his head.

Geeezzzz...................................

Walter Bright wrote:
> Christopher Wright wrote:
>> Awesome! I'll add this to wiki4d. Might I also suggest adding it to some reasonable location on digitalmars.com and bugzilla?
> 
> I think the wiki is the best place.
> 
>> What do you do about examples that should explicitly not compile? For example, a test for the fix to an accepts-invalid bug? Do you have to use tricks with __traits(compiles) and static assert (!is (typeof))?
> 
> I'd eventually like to go that route, but currently it is a long list of files that are compiled one by one and tested to see if the compilation return a non-zero exit status.

Now that you're more used to *nix, would it be productive to have all of the test harness on *nix?

It would make it immensely easier to, say, have it made so that both "do not compile" and the opposite, merge smoothly in the whole.

Georg Wrede wrote:
> If you consider a patch incomplete,

The author of the patch says it's incomplete in bugzilla.

> wouldn't it be more appropriate to address the issue, than waiting (days, years??) before you get put back-to-wall about it???

There's a long list of things to be done. There seem to be a hundred posts a day here wanting to be read and replied to. There's keeping an eye on the other programming sites for D stuff. There's the blogs I write for DDJ. There's the seminars I'm working up materials for. There's a thousand issues in bugzilla. *Everything* wants my attention.

314 is not breaking anyone's code, it isn't preventing anyone from doing their work. Fixing it completely is not trivial, it'll take some concerted effort to figure out a correct and complete fix. There are far more important issues in bugzilla to be concerned about.

I *have* to triage things.