Re: CVS policy

[Daniel Veillard <Daniel Veillard w3 org>]

> Recently, Marco from the Galeon project asked to have Galeon imported
> into gnome-cvs, and for accounts to be created for the active Galeon
> developers. This sparked a discussion of what kind of policy we want
> for importing new projects into gnome cvs, and for creating gnome cvs
> accounts.

  In this specific case I think getting Galeon into Gnome CVS makes
perfect sense. It's a very promising Gnome application and from my
small experience with both Galeon and Nautilus they both shared the
same kind of problems related to the interface with Mozilla component,
getting both develoopers community closer sounds a good thing, sharing
the same CVS is one step forward IMHO.
  As Ali pointed out it would be interesting to know what motivated the
Galeon developpers for asking to migrate to Gnome CVS. One thing we should
try to avoid is doing incomplete migrations, i.e. having 2 CVS base
available, this confuses users a lot !

> There's two major schools of thought on this.
> 
> One is best represented by Elliot. He thinks we should keep tight
> reins over adding new projects and new people, because if we draw the
> line wider than the core components of Gnome, we may end up not being
> able to say no to anyone. And endless growth is not a good option,
> because we don't have per-module ACLs or any of the other things
> needed to provide a good, complete hosting service.

  I wonder how many people are in need of ACL or ACL like mechanism
for large CVS base. As W3C CVS base maintainer this is one of my major
issues with CVS right now. Pointers on existing solutions would be
appreciated. But ACL are not users friendly, I far prefer having
the commit policy written in the HACKING file of a project than relying
on obstrusive system enforcement (unless very cleanly integrated).

> I have a different point of view (which I think is one that Havoc and
> Owen mostly agree with, but they can speak for themselves) which is
> that we should be permissive and generally accept gnome-affiliated
> projects that want to be included, especially if they are popular and
> actively maintained, and the sort of thing that might be put in a
> Gnome release or a Gnome extra apps release at some point.

  I agree. How do we define "gnome-affiliated projects" ? It seems
that dependency on Gnome libraries is one such criteria, but it should
be refined (using just libxml or glib would not count, would using
just gtk+ be acceptable too ?).

> If ACLs are
> a serious concern, that is something we should come up with a solution
> for. But the benefits of having major gnome projects all on one cvs
> server are fairly significant; it makes things a lot easier for people
> like me who build stuff from source all the time.

  there are other technical issues:
    - resource usages:
      + bandwidth for gnome CVS server is good, thanks to RedHat connectivity
        we should make sure that there is room for groth before importing
	popular and large projects
      + disk space
      + will anonymous server mirrors be able to keep up ?
    - maintenance:
      + there is currently nearly 400 top level directories in that CVS
        base, do we clean up at some point, how ?
      + who manages admin requests: creating logins, importing stuff ...
      + the larger the CVS base the harder to keep the bonzai and other
        indexing tools scaling properly.

Daniel

-- 
Daniel Veillard w3 org | W3C, INRIA Rhone-Alpes  | libxml Gnome XML toolkit
Tel : +33 476 615 257  | 655, avenue de l'Europe | http://xmlsoft.org/
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Rpmfind search site
 http://www.w3.org/People/all#veillard%40w3.org  | http://rpmfind.net/

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers