[asterisk-dev] Corydon76

[Koopmann, Jan-Peter]

On Tuesday, May 02, 2006 11:15 PM Tilghman Lesher wrote:

> Bug 6316.  While this illustrates exactly what you should do when
> your patch is rejected, it also illustrates that the process really
> comes down to the question of whether your patch is needed (i.e. for
> a bug) or has a definite utility (for a feature).  

I sort of fail to see the difference. In this case it turned out to be of use to quite a few people. You closed the bug even though I explained to you why the proposed workarounds are not sufficient. This does give a user the feeling that a few godlike people decide what is needed and what is not. You personally think the workaround is ok (even though there are arguments presented on why this might not be true for everybody) and threfore reject this small feature. I'd say this illustrates exactly how not to treat/reject a patch in the first place. At that time I was already so pissed that I decided to simply patch my own Asterisk installations and not care to discuss this with you anymore. If Tony had not requested to re-open this, the patch still would be rejected. Is this "what you should do when your patch is rejected"?


> I'd say a fair
> portion of the bugs that I've closed in the bugtracker are from
> people who don't realize that what they want to do can already be
> done, and then it's just a matter of education.      

It is one thing to say "Hey this does not work, it is a bug" and another to say "Hey this does not work as expected, I created a small enhancement, see the patch attached" like it was in this case. Please do not treat me as someone whining the moment something does not work as I expect it. I might have given this impression with one or two bugs but that is not what I do. If I fail to understand something I try to get help on -users or IRC first and do not simply open a bug. I am old and experienced enough for discussion. The only one allowed to educate me is my wife and don't you dare tell her I just said/wrote this! :-)

>> Even if later on it turns out that the question was not so dumb
>> afterall bad karma stays.
> 
> Examples?

Sure:


Bug 6152. First reaction: Already implemented, go away (even though not by you). It later turns out that the functionality is not yet present and is far more complicated than just CDRs. Therefore the original answer was not correct and the question valid. Not only are there four other persons in this bug asking for the feature even mattf says some work needs to be done here in order to even fetch the AOC information from chan_zap correctly. Bad enough someone adds bad karma for this question but it is even worse not to take that karma away once you recognize the question was not so simply answered in RTMF style.

Bug 6183: This _can_ be done in the dialplan. For several reaons I pointed out this is not easily done and therefore I still think the feature request was valid. Moreover I produced a perfectly working patch for this. Even oej thought it might not harm to add the patch. After it was finally rejected I discussed this with you guys on IRC and while I am not entirly happy having to do this via LOCAL, it does work and I can accept this being rejected in the end. What is hard to accept is to receive bad karma for this because it was not a clear RTFM configuration issue, more a feature request with a working patch. It was wrong to categorize this as a bug and not a feature request and it maybe was wrong to post it as major. 

The thing is, at that time I was an absolute Asterisk newbie and tried to contribute. Being a newbie I might have done things wrong in the bug tracker. But after a few bug reports and feature requests I was soon demoralized. Making a small mistake in bug tracker results in bad karma and "go away". Perfectly valid feature requests (see AOC and the discussion I started here) are not followed up upon. Generally I get the feeling that the needs of European users (many ISDN BRI) are not understood or not cared about that much. It might surprise some people but rumors tell there is human life outside the U.S. and some of them even have phone lines that are much more advanced than the U.S. phone system. :-) Unfortunatly in order to at least partly use this functionality you have to use things like bristuffed since the development in the official Asterisk system is progressing so slowly or not at all (see AOC discussion a few weeks ago here on -dev).

Another example for very slow progress: bug 6264. Definatly a bug. Fix is working here and in bristuff as well for months. Unfortunatly it has not been touched by any of the bug marshalls for 3 1/2 months. It is easy to shut people up using RTFM or "bug closed" but then on the other hand at least small bugs like these should make it to trunk easily as well. We are not talking about a major chan_sip restructuring here but a few simple lines in app_dial!

Due to customer projects I barely have time at the moment. And in that spare time I am thinking twice now whether or not to spend it on bugs/features in Asterisk due to the experiences I have had. I am afraid this has to change in order to get more people helping in the project since I strongly doubt that I am the only one feeling this way. Due to my poor coding skills you will surely survive me not putting my full strength to Asterisk but I would not like to see other really good guys being driven away by things like this. 

> You're right.  I apologize for being so short with Casper.  What I
> really should have said is "Please discuss this with another bug
> marshal, prior to reopening this bug."  

While this is not perfect either it would have been a lot better.

> I will consider this in the future.

Thank you very much!


Kind regards,
  JP