X.Org Foundation - Release Call - 3rd May 2004

[Egbert Eich]

Leon Shiman asked me to post this message here on his behalf
as his posting has bounced. 
I'll try to figure out why.

Date: Wed, 12 May 2004 10:34:00 -0400 (EDT)
From: Leon Shiman <leon at magic.shiman.com>
Subject: Re: X.Org Foundation - Release Call - 3rd May 2004
To: release-wranglers at freedesktop.org

MIME-Version: 1.0
Content-MD5: Bg2AC6J0YcjuHVVH0NLv4w==

on Wed, 12 May 2004 15:44:38 +0200 Egbert Eich wrote:
>To: People working on X software releases >
>Daniel Stone writes:
> > From one half of the 'complainers', this would be a step backwards.
> > Subversion is really CVS dressed up with a nicer method of branching,
> > proper copies, et al, and has its own reliability/scalability issues,
> > not to mention the not-infrequent protocol/on-disk format changes.
> > 
> > I was personally gunning for Arch. Full disconnected operation, proper
> > changesets and GnuPG signing of them, crazy branching and crazier
> > merging (in a good way). It's really the only SCM system that scales,
> > and it's fantastic for people working on completely unrelated things in
> > branches, or people working offline, or whatever.
> > 
>
>CVS is a tool that is widely deployed. It is well known and people know
>how to work with it. It is know to be stable (more or less). I don't
>say it is perfect - and some features are definitely missing.

This is important. If we wish to provide a stable standard, then it is 
important to recognize other de facto standards as well. that does not 
however mean we do not innovate and promote change. That is part of the 
strength and promise of FDT. We have the option of facilitating change by 
supporting the development of alternative tools.

We need both. But this means of course increasing the number of active 
participants...

I share Egbert's concerns and Daniel's desire for a technically better 
solution. but without recognizing common practices and knowledge, we risk 
marginalizing our acceptance. We can choose to share the burden of changing 
specific common practices and knowledge.

Leon

>
>If we are going to replace it we make the burdeon on people who want
>to get involved even higher. 
>On the one hand you want to get rid of Imake with the argument that
>it is not widely know yet you suggest to exchange the revision control
>system with something that is not well known.
>
>Furthermore any proposed revision control system must be compatible
>across versions. This must be guaranteed before we can even start
>considering it. This is essential in a distributed development 
>environment.
>
>Egbert.
>