cfengine-develop
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfengine-develop] Stable and development versions


From: Mark Burgess
Subject: Re: [Cfengine-develop] Stable and development versions
Date: Mon, 3 Mar 2003 09:48:23 +0100 (MET)

> I'd like your opinions about Cfengine's development cycle.
> 
> At present, we have the situation where bug-fixes are mixed in with
> new features in every stable release. I would love to see a stable
> branch and a separate development one.

I do what I can manage. That's all I can offer.
 
> The situation we had in the early days of Cfengine 2 was pretty hard
> on the users. Version 2 wasn't out of alpha-testing yet it was the
> only one having bug fixes applied. Version 1 was known to be solid
> but largely unsupported.

The alpha versions all came with a governement health warning.
Version 2.0.0 when released was pretty solid. There have only been
fairly esoteric problems with v2 - like multiprocessor bugs.
These are fixed now as far as I know.

> With more developers, can we do something to improve this? If not,
> I'll be releasing periodic patches to fix up the current stable
> Cfengine, whatever version it is, based on my Debian work and on
> patches submitted to the mailing list.

Sounds great, but one reason for starting this group is to shield myself
from some of this bug-fixing noise. I would like to see a split between

* patches that are bug fixes
* patches that are feature requests

The latter need much more attention than the former. They are not necessarily
to be accepted. 

I don't know what is a good way to do this. That is why I would like
for us to meet. What we are doing now is exactly what I was hoping
to avoid -- i.e. writing long emails that I have little time to read
carefully and then misunderstanding one another. Everything is so much easier
when we can look each other in the eye.

To get this process started, it is important to not let grand visions
get in the way of real progress. The stages I see are these:

 * Remove as many limitations as possible without sacrificing compatibility
 * More radical redesign, with tidying-up of deprecated nonsense.

Mark

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





reply via email to

[Prev in Thread] Current Thread [Next in Thread]