From: Scott Yeadon <scott.yeadon@an...> - 2004-07-22 01:19:28
Do we know how Apache manage their source - perhaps a similar model could work?
I suspect the second option is best, the first isn't scalable. I also like Jim's suggestion on a guide to an Eclipse hook-in to sourceforge - Eclipse or no Eclipse, I think the least that will be needed is a "Guide for Contributors" to ensure a process is followed by all contributors now and into the future for updating the Sourceforge code. The sponsorship idea also seems good, but may still run into the same problems as 1. if many changes and too few authorised committers.
I haven't done more than run up Eclipse and have a quick look, but it's likely to be the tool we end up using for further development at ANU.
Subject: Re: [Dspace-devel] Recommendations for contributors
From: Jim Downing <ojd20@...>
To: dspace-devel <dspace-devel@...>
Date: Tue, 20 Jul 2004 14:58:48 +0100
On Tue, 2004-07-20 at 14:41, Tansley, Robert wrote:
>> Hi all,
>> I've been thinking about approaches to recommend to people who are developing code they wish to contribute to the main DSpace code base (e.g. Naveed's WAI compliance work). I can think of two approaches:
>> 1/ work against a particular release of DSpace (e.g. 1.2). This has the advantage that the work can easily
>> be released as a patch against that version for those who wish to use it. The disadvantage is that the core
>> code in CVS may have changed and merging the patch into CVS may be tricky further down the line.
I think the merge costs will be prohibitive, and it will be difficult to
keep tabs on who's taking the software in which directions.
>> 2/ work against the latest CVS checkout, doing regular cvs updates, to ensure that your work doesn't stray
>> from the main branch. This means your work is more 'bleeding edge', and occasionally the code in CVS may
>> not function fully so testing your own code becomes more complicated. However, your code is always in a
>> good state to patch into new releases and roll into CVS.
Of course, the problems could be reduced by not checking in broken code!
>> Any ideas?
To make option 2 more palatable it might be a good idea for anyone doing
significant work on dspace to be 'sponsored' by a specific committer
who'll make sure their patches get tested and into cvs quickly. Would
also be worth a quick howto on hooking eclipse up to sourceforge cvs. jim