[OpenSER-Devel] SF.net SVN: openser: [4329] trunk/modules/benchmark/benchmark.c

[Bogdan-Andrei Iancu]

Hi Olle,

Any input or opinions are welcomed - otherwise we would not have this 
discussion on the mailing list, just to spam people :).

First of all, I guess the functionality I added got a mythical size 
during the discussion. Actually the change did not affect any of the 
current designs or architectures of OpenSER. It is just TM providing a 
new type of script route to cover some cases that were not handled so far.

When I refer to a major new feature, I think of TM refurbish, TCP 
reworking, new message processing flow, asynchronous support, script 
reload or stuff of this magnitude.
But there was no altering of the any existing behaviour, architecture, 
design and there were like 40 lines of code.

I really hate this discussion because it was invoked as technical (but 
not valid argument was brought in), than moved to project policy (but no 
rule - written or not-written was broken) and so on...

All the arguments that were brought in against had more or less no real 
basis.  This "witch hunting" really make me wonder if this discussion is 
not actually only about personal opinions like "I do not like this new 
functionality" or "nobody came to me to ask my opinion" or "if I do it, 
I will do it better"......
And I hate it, because there is no place for such opinions in an open 
source project.

Also please see my inline comments on your input.

Regards,
Bogdan



Johansson Olle E wrote:
> Just my 10 cents as an outsider, not going into the details, but more 
> the process.
>
> 9 jun 2008 kl. 15.30 skrev Bogdan-Andrei Iancu:
>>
>>
>>    - if you had so great ideas, nobody prevented you from implementing
>> such functionality. Again, being passive and later commenting on
>> somebody else's work is not really nice at all.
>
> I think this was a major new feature and it was presented very shortly
> before code freeze. That means very little time for discussions on an
> architecture level, which is needed when you see new code that
> implements something in the core of a product. Commenting on
> somebody else's work is a natural and desired thing in an Open Source
> project. Yes, I kind of take it personally if people realize that I'm
> as bad at coding as I really am, but for the project it's a good thing 
> (TM).
[bogdan]

I was referring to a different kind of meaning for "commenting" and in a 
different context: The feature was discussed several times on mailing 
lists and tracker by several people (and the actual code/idea was a 
result of that discussion). The "comment" I  was referring (which I do 
not enjoy) is the comment coming after the work was done, from a person 
who had no input during the previous discussions. And the context is 
when the "comment" sounds like "I do not like the code" + "it breaks the 
release", etc...

I hope you see my point here.
>
>>
>>
>>    - if you really have some improvements on this, there will be an
>> openser 1.5 were you can contribute.
>
> I don't really know the details of the OpenSER release policy, but if 
> it was Asterisk,
> having this in the 1.4 release would mean that we could not do any major
> changes since we have to be backwards compatible in the coming release.
> It's just too late when people are starting to use it as part of a 
> release.
> I think that was one reason for Daniel's reaction.
[bogdan]
This is not the case - it is not a major change to have such an impact 
on the future releases. And this does not explain nobody's reaction.
>
>
> Exactly this happened in an earlier release of Asterisk and it will 
> take a
> very long time to get rid of this function, that was and still is very 
> poor.
> Third party developers depend on this broken function and we know have
> to find ugly workarounds to keep supporting it while trying to fix the 
> problem.
>
> Again, I don't have any opinion on the particular feature, but based 
> on my own experience
> I do understand that other developers feel that this could have waited to
> next release so there was time to discuss this fully, not in theory, 
> and based
> on your code submission.
>
> As you know, there are many ideas being discussed on mailing lists and
> meetings but it's not until you actually have code that you realize 
> that it's
> for real and time for everyone to go through it, participate and 
> contribute.
[bogdan]
Exactly my point -  each new functionality has a start; and as we cannot 
fully design it from the being (by just discussing), there is a need for 
an embryonic piece of code to  server as based  for further  discussions 
and expansion.
So, I would have expected a more positive approach on the topic - like 
"ok, it is a start and here are some ideas to make it better in the 
future" rather than "I do not like it, it is bad code, let's stop the 
release"
>
> In Asterisk, we tried to have two fcode reezes. One for major 
> architectural changes
> (like this) and a later one for small features - applications, 
> functions and stuff
> outside of the core. Maybe that could be an idea here as well. I think 
> it worked
> well for us.
[bogdan]
unfortunately  there is no such rule for Openser - maybe it is the time 
to get something like this - it will spare us for such discussions in 
the future.
But for now, we are governed by the current rules.

>
> Again, I have not looked into the particular issue and I don't judge. 
> Just
> trying to understand the discussion and by comparing with my experiences
> in another project, give my feedback, the less than 10 EuroCents :-)
[bogdan]
As said, this discussion did not provide any positive result on the 
technical part, but maybe it will help in developing better rules to 
govern the project - by better I mean more clear and strict rules to 
avoid discussions like this one.
>
> Regards,
> /olle
>