23 Nov
2006
23 Nov
'06
5:43 a.m.
Hi Andrei!
Andrei Pelinescu-Onciul wrote:
On Nov 22, 2006 at 12:39, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
[...]
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.
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 :-) Speaking of copying/porting ser between ser and
openser I have a few
requests:
1. 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.…)
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?
2. 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
--
Klaus Darilion
nic.at