guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RFD: CVS or Arch?


From: Andreas Rottmann
Subject: RFD: CVS or Arch?
Date: Wed, 03 Dec 2003 19:23:30 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Hi!

I'd like to start a discussion among all the people interested in
contributing to the guile-gnome project on the choice of the source
configuration managment (SCM) tool. As you probably have read out from
my previous mails, I've started adopting arch for my work on
guile-gobject, and now have left the newbie state (at least I think so
;-)) and feel confident enough with it to propose it as primary SCM
for the upcoming guile-gnome project.

For some reasons on why arch is preferable over CVS, please see [0].

So here is the setup I'd like to propose for discussion:

* guile-gnome-common: arch category hosting common infrastructure,
  such as the autogen-support.sh stuff, common m4 macros and the like

* guile-gnome-gobject: arch category hosting the absolute core 
  (this is what ATM mostly is in gnome/gobject)

* For each binding: a guile-gnome-<binding> category, hosting the
  binding (spec, C support code, ...)

Then, we can combine these into meta-projects as we like, for instance
one guile-gnome package covering the developer platform and a
guile-gda package that covers libgda only. We'd probably also have a
guile-gnome-all meta-project, for all those that want to hack on many
bindings (we'd probably release an official tarball for that, though).

I still have to play around a bit with arch meta-projects, but from
what I can see, they are perfectly suited for release managment.

Of course, CVS access should also be offered, for those who can't (or
don't want to) use arch, such as the casual developer that desparatly
needs some feature from the development version, so we'd need an
arch->CVS gateway. This can be fully automated, if we use tla-pqm (see
[1]). That way every developer hacks on his own archive. Once she has
reached a milestone (this would be the time of 'cvs commit', when
using CVS), she issues a merge request, which then gets handled by the
next patch queue manager run, which will merge the developers changes
into the master repository (presumably hosted on savannah). After this
is done, the changes can be automatically synced into the CVS
repository.

[0] http://gnuarch.org/bin/view/Main/ExecutiveSummary
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

This reality is really just a fucked-up dream -- Papa Roach




reply via email to

[Prev in Thread] Current Thread [Next in Thread]