www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback on bug reports

reply David Ferenczi <raggae ferenczi.net> writes:
Hi Walter,

do you see it possible to give some more feedback on reported bugs?

There are quite many bug reports (some of them are fairly old) left without
any comment, confirmation/rejection. This leaves the reporter in
uncertainity (will it be fixed?, how long will it take?), which isn't
really inspitring.

IMO the following would greatly improve the process:

1. If a new bug is reported, it should be confirmed or rejected shortly
after it's been reported. This is also a good occasion to ask the reporter
for further information or action, if they are needed. This makes a good
impression on the reporter, that the bug is taken care of.

2. If the bug is confirmed it should be also (re)prioritised. This helps the
reporter to estimate how long will it take to fix the bug. Is it due in one
of the following releases or maybe someday?

3. Special attention to older bug reports or reconsidering the priorities
from time to time may help not to have these aging bugs around.


I hope that the above ideas may be applied for your day to day work without
major effort.


Regards,
David
Mar 11 2007
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Maybe because the current bug-tracking system is a bit messy and not 
very user-friendly. (or is it just me?)

David Ferenczi wrote:

 Hi Walter,
 
 do you see it possible to give some more feedback on reported bugs?
 
 There are quite many bug reports (some of them are fairly old) left without
 any comment, confirmation/rejection. This leaves the reporter in
 uncertainity (will it be fixed?, how long will it take?), which isn't
 really inspitring.
 
 IMO the following would greatly improve the process:
 
 1. If a new bug is reported, it should be confirmed or rejected shortly
 after it's been reported. This is also a good occasion to ask the reporter
 for further information or action, if they are needed. This makes a good
 impression on the reporter, that the bug is taken care of.
 
 2. If the bug is confirmed it should be also (re)prioritised. This helps the
 reporter to estimate how long will it take to fix the bug. Is it due in one
 of the following releases or maybe someday?
 
 3. Special attention to older bug reports or reconsidering the priorities
 from time to time may help not to have these aging bugs around.
 
 
 I hope that the above ideas may be applied for your day to day work without
 major effort.
 
 
 Regards,
 David
Mar 11 2007
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Hasan Aljudy Wrote:


 Maybe because the current bug-tracking system is a bit messy and 
 not very user-friendly.  (or is it just me?)


<snip top of upside-down reply>

Would you care to elaborate on what you think is wrong with the system?

Stewart.
Mar 12 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Stewart Gordon wrote:

 Hasan Aljudy Wrote:
 

 Maybe because the current bug-tracking system is a bit messy and 
 not very user-friendly.  (or is it just me?)


 <snip top of upside-down reply>
 
 Would you care to elaborate on what you think is wrong with the system?


I think he is targetting the system's user interface, not the actual 
system itself, which might be quite good in general. I have to admit, 
though, it doesn't feel too intuitive to me, either.

Best regards,
Alex
Mar 12 2007
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Alexander Panek wrote:

 Stewart Gordon wrote:

 Hasan Aljudy Wrote:


 Maybe because the current bug-tracking system is a bit messy and not 
 very user-friendly.  (or is it just me?)


 <snip top of upside-down reply>

 Would you care to elaborate on what you think is wrong with the system?


 
 I think he is targetting the system's user interface, not the actual 
 system itself, which might be quite good in general. I have to admit, 
 though, it doesn't feel too intuitive to me, either.
 
 Best regards,
 Alex


Yes, I'm talking about the interface (hence user friendliness).
Mar 12 2007
prev sibling parent reply David Ferenczi <raggae ferenczi.net> writes:
It seems that this request has been silently ignored. Rejecting would be ok,
but ignorance is more than disappointing.

I would like to understand the reasons.

Could anybody give me some short explanation on this?

Regards,
David
Mar 16 2007
parent reply torhu <fake address.dude> writes:
David Ferenczi wrote:

 It seems that this request has been silently ignored. Rejecting would be ok,
 but ignorance is more than disappointing.
 
 I would like to understand the reasons.
 
 Could anybody give me some short explanation on this?


It's a one-man project, so the reason there's not much feedback is 
shortage of manpower.  It's just the way it is, we've all had to get 
used to this fact.  A one-man project that creates free products can't 
provide the same level of customer support that a commercial project 
can.  Hope this explains it.
Mar 16 2007
parent reply David Ferenczi <raggae ferenczi.net> writes:
 It seems that this request has been silently ignored. Rejecting would be
 ok, but ignorance is more than disappointing.
 
 I would like to understand the reasons.
 
 Could anybody give me some short explanation on this?


 
 It's a one-man project, so the reason there's not much feedback is
 shortage of manpower.  It's just the way it is, we've all had to get
 used to this fact.  A one-man project that creates free products can't
 provide the same level of customer support that a commercial project
 can.  Hope this explains it.


Thanks, I agree. But I think it somehow also lies on the topic. There are
topics, which get attention immediately, and there are others, which never.

The point is, just like in case of bug reports, to get some feedback. Let it
be even a single line.

If you have a community around your project, it is necessary to communicate
with them. Or just define some rules, if you don't have time for it. E.g. I
don't answer mails, newsgroup post, except for...

The worst can happen to enthusiast users that they get ignored. This makes
also the recommendation of D questionable.

My suggestion addressed this kind of situation at bug reports. And the
impression is (maybe the truth is totally different) that nobody cares.
Mar 16 2007
parent reply torhu <fake address.dude> writes:
David Ferenczi wrote:

 It seems that this request has been silently ignored. Rejecting would be
 ok, but ignorance is more than disappointing.
 
 I would like to understand the reasons.
 
 Could anybody give me some short explanation on this?


 
 It's a one-man project, so the reason there's not much feedback is
 shortage of manpower.  It's just the way it is, we've all had to get
 used to this fact.  A one-man project that creates free products can't
 provide the same level of customer support that a commercial project
 can.  Hope this explains it.


 
 Thanks, I agree. But I think it somehow also lies on the topic. There are
 topics, which get attention immediately, and there are others, which never.
 
 The point is, just like in case of bug reports, to get some feedback. Let it
 be even a single line.
 
 If you have a community around your project, it is necessary to communicate
 with them. Or just define some rules, if you don't have time for it. E.g. I
 don't answer mails, newsgroup post, except for...
 
 The worst can happen to enthusiast users that they get ignored. This makes
 also the recommendation of D questionable.
 
 My suggestion addressed this kind of situation at bug reports. And the
 impression is (maybe the truth is totally different) that nobody cares.


I fully agree with you.  I expect the situation will improve sooner or 
later, forced by increasing adoption of D.  How it's going to happen 
remains to be seen.
Mar 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:

 David Ferenczi wrote:

 It seems that this request has been silently ignored. Rejecting 
 would be
 ok, but ignorance is more than disappointing.

 I would like to understand the reasons.

 Could anybody give me some short explanation on this?


 It's a one-man project, so the reason there's not much feedback is
 shortage of manpower.  It's just the way it is, we've all had to get
 used to this fact.  A one-man project that creates free products can't
 provide the same level of customer support that a commercial project
 can.  Hope this explains it.


 Thanks, I agree. But I think it somehow also lies on the topic. There are
 topics, which get attention immediately, and there are others, which 
 never.

 The point is, just like in case of bug reports, to get some feedback. 
 Let it
 be even a single line.

 If you have a community around your project, it is necessary to 
 communicate
 with them. Or just define some rules, if you don't have time for it. 
 E.g. I
 don't answer mails, newsgroup post, except for...

 The worst can happen to enthusiast users that they get ignored. This 
 makes
 also the recommendation of D questionable.

 My suggestion addressed this kind of situation at bug reports. And the
 impression is (maybe the truth is totally different) that nobody cares.


 
 I fully agree with you.  I expect the situation will improve sooner or 
 later, forced by increasing adoption of D.  How it's going to happen 
 remains to be seen.


I was watching this Google Tech talk:
http://video.google.com/videoplay?docid=-4216011961522818645&q=poisonous+people
from the guys who run Subversion.

One of the things they mention in there is the importance of 
responsiveness, and they suggest that some member of the project should 
be made responsible for addressing all issues that come into the mailing 
lists that seem to get dropped.

That's great for a truly open-source project, but the problem with that 
suggestion for D is that no-one besides Walter, and maybe now Andrei, is 
really a "member" of this project.  No one besides Walter has any 
ownership, so nobody really has any more obligation (or authority) to 
respond to posts than anyone else.  There probably are people here who 
would step up to the plate and take on such responsibility if they were 
given some authority, but no-one has such authority now.  Especially if 
you want to know "why isn't bug 2345 being fixed?".  No-one knows that 
besides Walter.  So if someone is going to communicate that to you it 
has to be someone who has Walter's ear.

As it is, only Walter (and maybe Andrei) really know what's going on, 
and it mostly goes on behind closed doors.  That's another thing that 
the subversion guys talk about in that video -- they say that wherever 
decisions are made in the svn project --- irc, face-to-face meetings, 
wherever --- they aren't ever considered "official" until they've been 
posted to the mailing list for all to see.

The upshot is that D just isn't really an open source project.  The 
source part (to the front end) is open, but the project part is not. 
And that's fine.  Stuff still gets done.  If you don't like it that way, 
then it's certainly something to consider when deciding whether to base 
your future on D.  It doesn't bother me too much because even if Walter 
got hit by a bus, D 1.009 works pretty well for what I need, and I'm not 
basing any sort of commercial venture on D.  Though if Walter did get 
hit by a bus I'd probably stop writing D code pretty soon after, because 
without Walter, D doesn't have much future.

--bb
Mar 16 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:

 torhu wrote:

 David Ferenczi wrote:

 It seems that this request has been silently ignored. Rejecting
 would be
 ok, but ignorance is more than disappointing.

 I would like to understand the reasons.

 Could anybody give me some short explanation on this?


 It's a one-man project, so the reason there's not much feedback is
 shortage of manpower.  It's just the way it is, we've all had to get
 used to this fact.  A one-man project that creates free products can't
 provide the same level of customer support that a commercial project
 can.  Hope this explains it.


 Thanks, I agree. But I think it somehow also lies on the topic. There
 are
 topics, which get attention immediately, and there are others, which
 never.

 The point is, just like in case of bug reports, to get some feedback.
 Let it
 be even a single line.

 If you have a community around your project, it is necessary to
 communicate
 with them. Or just define some rules, if you don't have time for it.
 E.g. I
 don't answer mails, newsgroup post, except for...

 The worst can happen to enthusiast users that they get ignored. This
 makes
 also the recommendation of D questionable.

 My suggestion addressed this kind of situation at bug reports. And the
 impression is (maybe the truth is totally different) that nobody cares.


 I fully agree with you.  I expect the situation will improve sooner or
 later, forced by increasing adoption of D.  How it's going to happen
 remains to be seen.


 
 I was watching this Google Tech talk:
 http://video.google.com/videoplay?docid=-4216011961522818645&q=poisonous+people
 
 from the guys who run Subversion.
 
 One of the things they mention in there is the importance of
 responsiveness, and they suggest that some member of the project should
 be made responsible for addressing all issues that come into the mailing
 lists that seem to get dropped.


Interestingly, this is kind of how Blizzard handles its customers in
World of Warcraft.  When you post on the forums, you basically "talk" to
the CMs (or Community Managers), not the devs.

So, let's say you ask "are Druids not supposed to tank in Kharazan?"
Presumably, a CM reads this and writes it down on his little list.  He
then goes off to the devs and says "yo ma homies, wats up wit the no
love on the bears goin' up the tower, man?"

And the devs kinda shrug and say "we'll get back to you," and then
don't, or just say "because."

And then the community gets pissy with the CMs for not doing their job,
which they really are, but the devs are still as busy now as they are
when they decided "we need someone to read the forums for us."

If the people reading the forums really know what's going on, then it's
OK; but if they have to go ask the devs, it seems to fall apart, and the
community just ends up feeling isolated from the dev team, and that
their concerns aren't being heard.

I've made two requests[1] of Walter in my time here (one big and one
small), and neither were ever responded to (by *anyone*, actually).  But
that's OK because at least I know that Walter is reading the forums.  He
usually just responds where he can to things that are important.

... or things that amuse him, but that's cool.  We all need a laugh once
in a while :)

Where was I?  Stuffed if I can remember :P

	-- Daniel

[1]: << Waves a tatty piece of cardboard with "return scoped instances"
and "set debug source file" written on it somewhat half-heartedly.  In
the rain.  With, I dunno... a blues track playing in the background, or
something. :P >>

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 16 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:


 And the devs kinda shrug and say "we'll get back to you," and then
 don't, or just say "because."
 
 And then the community gets pissy with the CMs for not doing their job,
 which they really are, but the devs are still as busy now as they are
 when they decided "we need someone to read the forums for us."


I don't think that would be an issue with the D community, though, since 
our "customers" are generally not 12 year old kids paying to play a 
game.  I think most people here would be satisfied with a response of 
"Walter's too busy for that one right now but he thinks it's a 
(good|interesting|terrible|vague) idea".  But we can't even get that 
unless there's at least *one* person Walter will respond to without fail.

--bb
Mar 16 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:

 Daniel Keep wrote:
 

 And the devs kinda shrug and say "we'll get back to you," and then
 don't, or just say "because."

 And then the community gets pissy with the CMs for not doing their job,
 which they really are, but the devs are still as busy now as they are
 when they decided "we need someone to read the forums for us."


 
 I don't think that would be an issue with the D community, though, since
 our "customers" are generally not 12 year old kids paying to play a
 game.  I think most people here would be satisfied with a response of
 "Walter's too busy for that one right now but he thinks it's a
 (good|interesting|terrible|vague) idea".  But we can't even get that
 unless there's at least *one* person Walter will respond to without fail.
 
 --bb


What makes you think the people whining are the 12 year olds?  My mother
plays in a guild for, er... I can't say "older people" since my mum IS
NOT OLD (Hi Mum!).  Let's say, people who are of an age where they most
likely are married with kids. :P

Anyway.  No 12 year olds in her guild.  She *still* has people bitching
and whining about utterly pointless and trivial things.  They complain
that they don't get enough loot, about class changes, about
*everything*.  Age has nothing to do with being pissy -- I think that
people only get better at it as they get more experienced at it ;)

That said, the vast majority of people on this NG *are* mature, sensible
people.  Of course, once D explodes in popularity, leaving Ruby a
shivering, nervous wreck in its wake, I'm 100% certain that we'll get
more than our share of whiners...

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Mar 16 2007
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Baxter schrieb am 2007-03-17:

<snip>


 That's great for a truly open-source project, but the problem with that 
 suggestion for D is that no-one besides Walter, and maybe now Andrei, is 
 really a "member" of this project.  No one besides Walter has any 
 ownership, so nobody really has any more obligation (or authority) to 
 respond to posts than anyone else.  There probably are people here who 
 would step up to the plate and take on such responsibility if they were 
 given some authority, but no-one has such authority now.  Especially if 
 you want to know "why isn't bug 2345 being fixed?".  No-one knows that 
 besides Walter.  So if someone is going to communicate that to you it 
 has to be someone who has Walter's ear.


Walter most certainly isn't the only one capable to fix the compiler.
Ignoring inline assembler (because GDC-0.23 doesn't support it on
AMD64) roughly 9% of DStress'[1] test cases with unexpected results
behave differently under DMD-1.009 i686 and GDC-0.23 AMD64. This
suggest that either DStress contains an overwhelming number of broken
test cases or a large proportion of all observed compiler issues are
due to the shared open source frontend.

Assuming pessimistically that 50% of the misbehaving test cases are
buggy would result in ca. 360 fixable test cases. A single bug usually
causes 1-10 failing test cases. Thus there are at least 36 bugs everyone -
yes this includes you - can fix and submit patches to GDC and/or DMD.

While the communication issue raised by the GPs is valid the question
why bugs aren't fixed seems to be a much more pressing one.

Thomas

[1] http://dstress.kuehne.cn


-----BEGIN PGP SIGNATURE-----

iD8DBQFF+9yELK5blCcjpWoRAujDAJ9WHt/JT1X15dSGUvQ+xOvZaaaz/wCfe/ov
2p4Ei3P1YXVwJPSC3RndGlo=
=gxpo
-----END PGP SIGNATURE-----
Mar 17 2007
parent "David B. Held" <dheld codelogicconsulting.com> writes:
Thomas Kuehne wrote:

 [...]
 While the communication issue raised by the GPs is valid the question
 why bugs aren't fixed seems to be a much more pressing one.


This is a great point.  While D is more of a Benevolent Dictatorship 
than an Open-Source community, there is a *lot* that the community can 
do without Walter (like Mango, Tango, DTL, DDT, Descent, DForms, etc. ad 
nauseum).  Fixing bugs is important, but working around bugs is an even 
more important skill.

I spent nearly 10 years of my life putting bread on the table with a 
commercial compiler with spotty support (Borland C++Builder).  People 
would report bugs on the forums on an almost daily basis, but you were 
lucky if 10% of them got fixed in any given patch.  Eventually Borland 
released a tool to help give visibility to the bugs and progress being 
made, but it simply was not realistic to expect that even a team of a 
dozen or more professional compiler writers were going to fix all the 
bugs.  Instead, you learn to code around them.

Consider Boost.  It's arguably one of the most advanced source code 
libraries in existence, but it probably has far more conditional 
compilation than the average library because it demands portability. 
Most of those conditional blocks are due to compiler bugs in one 
implementation or another, and yet Boost is a very high-quality product. 
  Aleksey Gurtovoy got Boost.MPL to compile on VC++ 6.5!  If that is 
possible, then I'm sure it is possible to work around a good majority of 
the bugs that exist in D.

That is not to excuse D bugs.  Walter should be lashed with a wet noodle 
for every bug that exists in the compiler.  But the reality is that if 
everyone were paying him a $1,000/year support contract, everyone would 
still have open bugs, all the time (I know, because lots of Borland 
customers had much more expensive support contracts, and they still 
complained about open bugs).

In my view, it is important to continue filing bug reports and telling 
Walter which ones cause the most pain.  But at the same time, it is more 
productive to work around the bug with an obvious and ugly static if 
(BUG_123456_ISNT_FIXED_YET) and make progress.  Since the vast majority 
of areas in which D could use improvement (library support, namely, but 
tools as well) do not require direct intervention on Walter's part, the 
community would serve itself best by figuring out how to contribute, 
rather than how to whine.  And at the end of the day, you will be able 
to say you got to participate in the development of D.

Another thing which might be helpful is to have a Top 10 Worst Bugs page 
on the wiki where users can vote for the bugs which cause the most pain, 
as a hint to Walter where his efforts would be appreciated the most. 
Maybe there's something like that already, but I haven't stumbled across it.

Finally, the best way to improve D is to take Thomas up on his challenge 
  and help fix the compiler tests.  If necessary, add finer-grained unit 
tests.  It may well be that half the bugs reported are fixable in userspace.

Dave
Mar 18 2007