Hi,
As described in an earlier posting on this list (from June 16th) CERN has been
using Savannah successfully since last December. We would like to take active
part in helping to develop Savannah further and bring in the features we have
included up to now. For this we have been in contact with Mathieu Roy
(yeupou) from the GNU Savannah Development team on how to best organize the
cooperation, especially in respect to handling of the Savannah code on their
CVS repository.
We came up with the attached proposal and we would like to ask the other
developers, whether they agree to this or whether they have any
improvements/additions.
Regards,
Derek
--
Dr. Derek Feichtinger Tel: +41 22 767 26 98
LCG/SPI Group email: [EMAIL PROTECTED]
CERN http://people.web.psi.ch/feichtinger
CH-1211 Genève 23
Proposal for how to organize the coordination between GNU Savannah and
CERN Savannah Teams:
1. Develop an extended data base structure.
-------------------------------------------
Some new features require extending the Savannah DB, so an extended
table structure should be developed. This should involve a discussion
on the savannah-dev list, where other users can make suggestions
depending on their requirements. Changes to the DB should be made very
rarely, so it would pay off to invest some work into a nice design.
2. CVS organization
-------------------
To prevent conflicts in the code, we propose this organization:
- All developers use the GNU Savannah CVS repository. Access to the
GNU repository can only be granted by the GNU Savannah
Administrator(s). CERN team members sign up personally, i.e. a new
team member will contact the GNU admin to be signed up (in the same
way as the other Savannah volunteers do). No developer may use the
identity of another to do operations on the CVS.
- The repository trunk contains the GNU Savannah version. The latest
release should always receive a release tag (this will make it
easier for other developers if they want to send in patches, for
then they have an easy point of reference).
- GNU Savannah's current working model implies, that the CVS HEAD
version is always a working version (for now it's even the version
running on the main server). If release tags are introduced, the CVS
HEAD can be considered the latest release version + bug
fixes/updates to this release. Development of experimental features
should happen on branches. A user who checks out the sources without
specifying a tag should always get a working version.
- Since changes on the HEAD version may impact the GNU server, they
should mainly be made by GNU Savannah developers in charge of the
server (still, it may be safer to no longer use a cron job to
synchronize the actual version on the server with the CVS HEAD)
- The CERN Savannah team will make a branch based on the latest
official GNU Savannah release. New features (or if it can't be
evaded: CERN specific features) are checked in on this branch, so
they don't interfere with the GNU Savannah trunk. If CERN implements
changes which are considered bug fixes to the trunk, they are first
checked in on the CERN branch and this is then communicated to the
GNU Savannah team. They can then easily merge the impacted files of
the branch with the trunk.
- CERN and GNU should work together in merging the major changes (i.e.
new features) to the main trunk. One must be careful to not let the
branch diverge too far from the trunk. So, if CERN has developed a
stable new feature, CERN should initiate the merge as soon as
possible. Communication should be done via the savannah-dev mailing
list in order to inform all other developers.
Suggestion: For local development at CERN a local CERN CVS repository
may still be used. I.e. it may be preferable to not do all atomic
commits to the CERN branch on the GNU repository, but only to
check in stable CERN releases. Both GNU and CERN would then
follow a work model as laid out in chapter 13 "Tracking
third-party sources" of the Cederqvist CVS manual, with the other
party's version being the "vendor" version (a drawback of this
method naturally is that the atomic commit messages are not
carried over by this procedure).
