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

On Wed, 2002-05-29 at 08:39, Harrie Hazewinkel wrote:
> 
> 
> --On Wednesday, May 29, 2002 3:45 AM +0100 Bruno Rodrigues 
> <[email protected]> wrote:
> 
> > On Mon, 2002-05-20 at 15:16, Stipe Tolj wrote:
> >> Oded Arbel wrote:
> >> >
> >> > Agreed. I was hoping that at least the billing issue (I remember it
> >> > being talked about in the list a while back) would interest people.
> >> > I do think, though, that fixes to problems not yet detected "in the
> >> > wild" should go in anyway : that's why it's called a "development
> >> > tree", if the solution does not break anything - of course.
> >> > IMHO, the current situation where the CVS build must never be broken
> >> > because it is the "production version" and so patches require careful
> >> > scrutiny before going in is not healthy. CVS _is_ the place to test
> >> > fixes and new features - when you require that people will download and
> >> > apply your patches one by one, the number of testers will shrink to the
> >> > number of people interested in the specfic patch - which in a
> >> > not-so-high visibility project like Kannel could easily get down to 1~2
> >> > people - or even less.
> 
> I agree. CVS is for development and users do not like to apply many
> patches themselves in order to get it into a certain state.

But kannel have some special kind of users. Besides the ones that wants
to test kannel against a modem or mobile, the majority are almost 
"power users" that don't get scared with terminology of stable and
unstable.

It's like beeing afraid of debian unstable :P



> > 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 ;)
> 
> You must be a lucky chap then. :-)

I just have the facility to being able to have a production system to 
do debugging, and some knowledge to fix quickly if something goes wrong
(and there's always the local bearerbox.old and smsbox.old ;) )