Hi Andrei!
Andrei Pelinescu-Onciul wrote:
On Nov 22, 2006 at 12:39, Klaus Darilion klaus.mailinglists@pernau.at wrote: [...]
I'm being told that some other personal affiliated with the same company more or less copied-n-pasted TCP code from the allegibly discontinued SER to OpenSER.
That's how open source works. I also copied lots of TLS extensions from ser to openser, and even extended it. You can also copy my extensions back to ser ... I would love to see it there :-)
I'm sure Jiri has no problem with copying code from ser to openser. We will do the same with some openser modules and we already did with some fixes. The problem here was that it was claimed that ser was dead but in the same time new code commited in ser was added in openser (so the openser history writer was not very well intended).
As I already said (maybe to less explicit) this is obviously false and should be fixed.
Speaking of copying/porting ser between ser and openser I have a few requests:
- If someone sends a fix for code taken from ser, which was not
modified in openser, please could you also bounce the message to the ser maintainer of that piece of code? If you don't to whom, just send it to me and I will make sure it reaches the right person. I'm asking this because my favourite pass-time is not to scan openser commitlogs for possible fixes to my code (e.g.:http://openser.cvs.sourceforge.net/openser/sip-server/fastlock.h?r1=1.2&...) and this will help me at a minimum effort for the openser developer part. Of course I think this is true not only for me, but also for other ser and openser developers and I (and I'm sure anybody else on the ser team) will return the favour.
This is a practice which must be done by the core developers. I often see bug fixes, but for me it is impossible to know if the fixes are for original ser code or for new code. In the beginning I watched the ser's CVS commits and forwarded fixes to the openser list. Some of them were applied to openser too, but not all of them.
I agree it would be nice if the core developers exchange fixes for common code - maybe a common mailing list would help for this?
- Please give proper credits for the code you port from ser.
I've saw several times things like: Foo sees something was fixed in ser or a new small feature was added and sends an email to the openser list (specifying that the change/patch comes form ser). The openser developers take the change, but the commit message says something like: fix for XyZ, credits go to Foo (ser is not mentioned at all). It would not only be polite, but it will also help us to filter more easily through the openser fixes.
I agree - it should be explicitly mentioned when a patch comes from ser.
Comming back to the openser - ser performance / features discussion, I think the important part here is how we can improve both sers (and you should take the test results as a bug report and maybe ask yourself how did this go through testing, even old sers were faster then 4000 cps).
You think the current openser has a bug because of the low performance? In this case it would be interesting to see how stable ser (0.9.x) compares to openser - if there is really a loss of speed in openser's tm module compared to its roots (ser 0.9)
If you think only of the users, then a combination of ser & openser will be the best version.
Of course - I was not happy about the split because it was clear that some features will be only in one of the two branches.
While we disagree (probably) in many respects, I think there are at least a few clear advantages each version has. For example openser has very impressive documentation (at this time ser is very far away from this point of view) and lots of new modules.
I agree - that's one of the reasons I prefer using openser also in new installations.
I still wonder why you do not the same. Autogenerate the README files from the xml files and put them on the webpage - this is what openser did (and some improving of the README).
You started a wiki which must be filled - thus you are starting from ground although there is already lots of documentation in the READMEs.
Further, I often see commits in ser with new features but without documentation. In openser it is not allowed to introduce new features without writing a documentation patch. Why isn't there the same rule in ser?
ser has also its share of new modules (though I think not so many) and a better/improved "infrastructure" (core, tm and lots of the "base" modules - we are actively improving them). ser code tends to also be more tested and stable (our release policies differ wildly).
Probably faster release cycles does not allow such heavy testing as you do - nevertheless openser1.0 was real heavy tested (by me).
I've tried looking at openser core & tm commits and I haven't seen any significant changes (and this is not a flamewar attempt).
Aren't the pseudo variables vs. select framework significant changes? Also TLS in core vs. TLS as module?
Now the question is why doesn't openser take the core, tm and a big part of the modules from ser completely and concentrate then in adding new modules (which you seem to do anyway)? Does it make sense to re-invent the wheel ?
I would like to see that too - although I sometimes commit code I am rather a user than a developer and of course I would like to benefit from all the new features in ser and openser.
Probably it is a matter of time. Replacing openser's core is sure lot of work. And maybe it is done if openser's core/tm will become a bottleneck.
Everybody (me too) suffers at least a little from the not-invented-here syndrome, but if you think of the users and at how much of your time it will save, it will make a lot of sense, even if some compromises would be necessary. I think the advantages will far outweigh the problems. Just think about it, we can concentrate each other on our favourite stuff and we can benefit much more easily from each other's work.
I'm completely with you - but this is something the developers have to agree - not the users (me).
regards klaus