[Asterisk-Dev] 'tonezone' in chan_zap.c

[Brian Capouch]

Kevin P. Fleming wrote:
> Preston Garrison wrote:
> 
>> I don't think it would hurt to have less of an attitude with these 
>> type of things.  Alot of really good developers don't have alot of 
>> time to poor through endless tens of thousands of lines of code to 
>> find out the answer to a simple question.  I think asterisk is missing 
>> out on alot of 
> 
> 
> "poor (sic) through endless tens of thousands of lines of code"? Give us 
> a break, please. Noone suggested that the poster needed to read and 
> understand all of Asterisk and Zaptel, but given that he had a specific 
> question about a configuration option, do you really think it would take 
> more than a 5-second 'grep' to find the code related that option?
> 

Hey Kevin, noone (sic) should mock people for the typos in their emails, 
huh?  We all get in a hury sometimes ;-)

> In fact, a simple 'grep' for 'tonezone' shows enough hits for just about 
>  anyone to figure out what's intended for.

Yep.  And then once the grepper pulls up the files, he can use the 
voluminous comments in the code itself then, to penetrate the logic of 
the half-dozen people who have separately hacked the code over time.

I am doing a class about Asterisk this semester at the little college 
where I teach, and one of the first things I told my students was, 
"Don't post to the Asterisk lists!!  Ever!!"

The truth of the matter is that the guru types on the Asterisk lists are 
far quicker to act like dicks to those who they deem beneath them than 
on any other OS list I subscribe to.  Whenever someone calls them out, 
they immediately cop this, "We're not being dicks; we're just too busy 
to screw with newbies" answer.

On the -users list I have come to appreciate Steven's helpfulness, even 
though it comes with the price of his occasional snippishness.

But on -dev, the rule of the day is that questions *about* the code are 
discouraged, even though this product is arguably the 
least-well-documented code I have ever tried to plow through.

In my own case, I've been reading code for weeks, trying to figure out 
just how to use (and extend) the Realtime engine.  The Wiki has some 
documentation, but it is cursory, self-contradictory, and in general of 
very limited use.

The code?  Well, there's not a shred of documentation anywhere 
internally, and to make the chase interesting, there are data structures 
sprinkled about that define structures of pointers to functions, 
indirect calls to those functions buried uncommented inside other 
functions, and then for good measure a whole function defined as a macro 
(REALTIME_COMMON).  To that add fragments of functionality scattered 
throughout the pbx code, the configuration parser, the various channels, 
and the resources directory, and the thought of someone just reading it 
and coming to a good understanding becomes vanishingly small.

That sort of thing is withstandable when you can fire off a mail to the 
developer and ask for some quick direction.  Oftentimes a couple of 
sentences from the person who wrote the code can be enough to jump-start 
what is otherwise a futile exercise in reading someone else's mind.

But not this bunch.  We are kept at bay by watching as the important 
people flame anyone on the outside who dares to ask for a bit of direction.

I am not so much angry about this as disheartened.  IMO, many people 
could be made into contributing members of the developer 
community--something I hope that everyone agrees is needed--but for 
their lack of enough of a masochistic bent to actually dare to ask for 
some background on this list and then be flamed to a crisp.

I'll shoulder on, and I'm sure the other posters here today will too, 
because the project is bigger and more important than any of our 
respective egos.

But dealing with all of this makes me pine for the sort of spirit I 
commonly see on other lists I'm on, where the developers are quick to 
help, and encouraging to those who are at a lesser stage of experience 
with the code than they are.  They know in the end their patience will 
help make the product better.

B.