Re: Re: 28 Aug 2003 Commit - Horde/IMP Versions?

Quoting "Gary C. New" <[email protected]>:

>>
>> I'm not sure if you know how development is done for these projects, 
>> but usually
>> what happens is that all new development is done with HEAD.  So in 
>> August 2003,
>> SAM worked with CVS HEAD (from August 2003).  For release versions, 
>> usually a
>> new branch is made in CVS and only bug changes/fixes are made to that branch
>> (so that it works with released version of the Horde framework).  If a
>> particular enhancement has worked fine in HEAD for some time, a 
>> developer will
>> sometimes take the fix and merge it from HEAD into the RELEASE branch.
>>
>>
>
> I was under the impression this was the case, but I wanted to confirm
> it.  I know this list get pounded with silly questions and I appreciate
> you taking the time to graciously answer mine.
>
>>
>> I don't know why you think SAM is unstable.  I'm using a version 
>> from CVS HEAD
>> that works just fine.
>>
>
> It isn't SAM HEAD I am concerned with being unstable it is HORDE and IMP
> HEAD.

I'll make a rough generalization for most of the Horde projects.  CVS HEAD is
fairly stable.

Can I get a version from CVS HEAD that doesn't work? Yes
Can I get a version from CVS HEAD that doesn't work with my existing data? Yes
Can I get a version from CVS HEAD that messes up my data? Yes

Does that mean it will do all of the above? No.  In fact I find that 
none of the
above happens that much, if at all.  Its just a risk.  There are some
(including me) who run CVS HEAD in production.  There are some who have 
60,000+
users and they run RELENG.  It basically depends on risk of bugs vs.
functionality. I find that I get tons more functionality (including the 
ability
to run SAM) for a few bugs here and there.  If you have thousands of users,
HEAD might not be for you.  I mean its like the Linux kernel.  2.4.x was the
released version of the software.  2.5.x was the development version.  But
thousands of people ran 2.5.x fine with no problems whatsoever.  So basically
I'm saying that development version != unstable.

>
>>
>> If you are willing to devote the time it takes to maintain and 
>> support a RELEASE
>> version of SAM, i'm sure the Horde developers will love for you to 
>> contribute.
>> Everyone is a volunteer and doing this in their own time, so I don't 
>> think you
>> can expect every package that they have to have a RELEASE version.
>>
>
> I would love to contribute, but I don't want to re-invent the wheel.
> Perhaps I can assist with a RELENG version when the project branches.
>
> At the moment, I am attempting to use Darik Horn's modified version
> dated 20030528.  I would prefer to write the amavisd_ldap driver for a
> useful version.
>

All new development is done against CVS HEAD.  The horde maintainers will not
take any patches (or new drivers) that work against RELENG version of the
software.  It just doesn't work that way.  The process works like this.  You
contribute software to SAM against the CVS HEAD version.  People use it for a
while, testing its functionality.  After sometime, when the appropriate 
version
of Horde is about to be released, a version of SAM that works against that
version of Horde will be packaged for release.  But first release candidates
are distributed to do further testing.

By developing new drivers against a RELENG breaks this model.  You now are
contributing possibly buggy code against a stable branch which defeats the
whole purpose of having a RELENG version.

>>
>> When CVS HEAD is relatively stable I take a snapshot and use this in my
>> production environment.  If your not willing to do this you have to wait.
>>
>
> How can you find out when Horde, IMP, and SAM HEAD are relatively
> stable?  I believe the Mozilla project calls these Milestones.  What
> would you recommend would be the latest Milestone equivalent for Horde?

I don't think there is any formal name and I dont' think Horde exactly follows
the Mozilla development modelm.  The way I determine whether Horde is 
stable is
by monitoring the CVS mailing list to see what types of commits have 
been added
recently.  If big chunks of functionality have been added, I stay away.  But
when there are only small/nit-pick type commits (which you can tell by the
descriptions on the commit) is when you should grab a version.  Will it be
perfect? No.  But it will be pretty stable.

>
>>
>> This is opensource, you can do whatever you like with code, including
>> contributing to the project to develop a RELEASE that works with a current
>> release of Horde
>>
>
> I would like to help further the project without re-inventing the wheel.
>
> I really do feel that the SAM project is a worthy effort, I am simply
> frustrated with its progress over the past year.  I do appreciate the
> efforts of those who do contribute, even if their bedside manner isn't
> as good as yours.

Well if you want to take a version of SAM from HEAD and port it to work with a
the last RELENG version of Horde, I'm sure the developers will accept it.  But
to develop new and untested functionality against that RELENG version will
never be accepted.  You will have to develop against CVS HEAD and follow the
model that is in place.

Amith


-- 
sam mailing list - Join the hunt: http://horde.org/bounties/#sam
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]