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

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

Re: guile-gnome's version control


From: Greg Troxel
Subject: Re: guile-gnome's version control
Date: Mon, 14 Aug 2006 08:34:38 -0400
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix)

  I'm growing quite frustrated with guile-gnome's VCS setup. The need to
  have many branches mirrored in strange places just to get sane offline
  operation is too much for my brain. Also, everyone else on the planet
  has moved away from gnu arch, and I think it's time we had something
  easier to use.

I never managed to get going with arch, really (and I'm the VC weenie
in my group), so I agree.  I'm sure I could have figured it out, but
it took too much effort.   And I'm not opposed to arch philosopically
- I think it's really neat.  (My only objection to it is the
opposition to being able able to store binaries - in the real world
you have to do that, although guile-gnome probably doesn't.)

Distributed systems have two good properties that you mentioned:

 a) random people can make and publish branches

 b) A private branch can become the real project if someone vanishes.

I think the distributed systems are very cool, but I'm not sure they
are necessary for guile-gnome, which is a small project and is likely
to remain so.  Here's my list of requirements for a VC system and
hosting serverice (which are related).

1. Easy for people to use who are the real contributors.  By "Easy" I
   don't mean "favorite", I mean simple and powerful enough that it
   doesn't get in the way.

2. Easy for people who want to try out the "CVS version", maybe make a
   small contribution (e.g. code, test, mail diff to list).

3. The build system (and module splitting, if any) should be
   completely decoupled from the revision control system.

4. VC tool should have stable storage representation, and we should
   expect it to be around and in common use in 5 years.

5. VC/hosting should allow for long-term project survivability without
   depending on an individual.  This means multiple committers, and
   multiple admins (those who can approve committers), perhaps backed
   by an organization with meta-root privs.

6. VC/hosting should allow for short-term progress without depending
   on anyone.   Thus, multiple people should be able to commit to the
   head and release branches, and make releases.

7. VC tool should support both head and release branches.  But
   guile-gnome is not yet stable enough to make releaes branches
   necessary.

8. It must be easy for a newbie to know where to get the latest code.

I would think a non-requirement is:

1. people should be able to create private repos, and branch, and do
   all this disconnected from the internet.

GNU Radio just went to SVN, and they have a branch for each developer
in the real repo, so people with commit privs can make (and publish)
private changes, although not without internet connectivity.

It seems that guile-gtk is a "GNU Project" (meaning copyright
assignment to FSF); I'm not clear on guile-gnome, but surely the FSF
would be willing to host it as a non-GNU project.

Given all this, and that darcs/etc. still seem boutiquish, I'd say
this should be in SVN on someplace like FSF Savannah, or even
sourceforge.

Also perhaps of interest, NetBSD is still using CVS (over 1 GB of
source when checked out).   CVS is getting creaky, but it's not a
serious impediment to the real work.



I would suggest that before you move to SVN or darcs, that you

1. merge all the patches around into the 'real' archive.
2. publish a 2.7.99 out of that, as alpha, and ask for testing.
3. If ok, publish 2.8.0 and ask packagers to update.

This will give "users" something ok to run during the move to the new
vc system.


Hope this helps. 

-- 
    Greg Troxel <address@hidden>

Attachment: pgpak5HlMkl13.pgp
Description: PGP signature


reply via email to

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