RE: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)

> 
> Well.. To be honest, using the CVS is an advantage because that way
> we get 100% testing and debug, code is done with less errors and bugs
> are fixed quicker ;)
> 
> I'm always using cvs in production. Some bugs are only visible on 
> production systems and I don't have time to do testings before 
> upgrading. And if some message is lost, I can always blame the SMSC ;)
> 
> 
> There's some structural changes that we should do, and for that
> we really need a different branch. Modularity, new autoconf, real
> unicode support, etc.
> 
> But for that, before thinking in branches and releases, we should
> think in the new architecture. 
> 
> 

I do not agree - we cannot even think of architecture changes while
everyone is building their production systems from CVS. while here we
also build our production from CVS by choice, for the same reasons you
stated, this is a "bad thing(tm)". it's our obligation to supply a
"stable" branch for people who rather have something that is known to
work, then the bleeding edge (which is most people). If we start doing
architectural changes on the CVS, while everyone is using it to build
their production, we will break things for people who don't/can't know
how to handle it.

So a branch is a must before doing any major surgery on the code.

--
Oded Arbel
m-Wise Inc.
[email protected]
(972)-67-340014
(972)-9-9581711 (ext: 116)

::..
Faith is believing what you know ain't so. 
	-- Mark Twain