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

[Gary C. New]

Amith,

Thank you for that great information.  It has cleared several things up 
for me regarding the Horde project as a whole.  With your responses and 
those of others on the horde-devel list, I believe I have a better 
prospective of the project and how I can better take part.

Keep up the great work.

Respectfully,


Gary


Amith Varghese wrote:
> Quoting "Gary C. New" <garycnew at yahoo.com>:
> 
>>>
>>> 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
> 
>