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?)

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?)

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?)

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