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

[Johansson Olle E]

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

>
>
>    - 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.

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.

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.

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

Regards,
/olle