--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.
>> > case in point is the +CMTI patch by Alex Judd -
>> > it seems like a perfectly valid feature, but only 2 or 3 people on this
>> > list are at the same time interested and skilled to test
>> > iX-Mozilla-Status: 0009tences where some of them cannot find the time
>> > to do so, this perfectly good feature would simply be abandoned.
Maybe it is also needed to establish of how many of the group
should support or oppose to it before it is decided to what will be added.
>> >
>> > I suggest we should roll out a "release" ASAP, using the following
>> > schedule :
>> > - branch the tree now (yesterday would have been a good time too ;-)
>> > and label it 1.2.0.
Why do you already want a branch??
Why not putting the releases into a branch??
(Just asking)
Since this way you just can keep developing.
As for a release I would suggest name it 1.2.0
Make a branch of it and do new releases as 1.2.x
Continue development in the main branch for 1.3.y.
>> > - bug fixes may be submitted to either of the trees, and then ported to
>> > the other.
>> > - new features may be submitted only to the HEAD tree.
>> > - features and bug fixes will be submitted freely to the HEAD tree with
>> > minimum checks for style and obvious coding errors.
>> > - the HEAD tree will be considered unstable and fit only for
>> > development work.
>> >
>> > Using this method we would not further degrade the current situation
>> > (where people who have problems are told to upgrade their production
>> > servers to the CVS version - as it is more stable), while stabilizing
>> > the development effort for a full fledged "stable" release w/o
>> > hampering further feature development.
If the current CVS version is way more stable, I think a new version is
an needed.
>> >
>> > Opinions please ?
>>
>> +1 for most of that.
>>
>> I was anyway concidering asking the developers about releasing 1.2.0.
>> I'd like to hear from Bruno, Andreas and some others what they think
>> about if current CVS HEAD is stable enough to make it a stable release
>> 1.2.0?
>
> 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 ;)
You must be a lucky chap then. :-)
>
>
> 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.
Depends, I would say. Maybe a release would require a branch
and keep working on head.
>
> But for that, before thinking in branches and releases, we should
> think in the new architecture.
I concur. The only thing is what kind of things do we put on the list.
You already mentioned some. After what we have to define how indeed.
Harrie
Internet Management Consulting
mailto:[EMAIL PROTECTED] http ://www.mod-snmp.com/
