Moving xlibs modules to xorg

[Keith Packard]

On Sun, 2006-03-05 at 23:14 +0200, Daniel Stone wrote:
> On Sun, Mar 05, 2006 at 12:08:35PM -0800, Keith Packard wrote:
> > I'm starting to migrate modules which were 'canonical' in xlibs over to
> > xorg. The first three of these are the newest extensions, fixes, damage
> > and composite.
> > 
> > At this point, I have them only in git form and have exported them as
> > such.
> 
> I have them in CVS form.  The whole repository.

X.org CVS has imports from xlibs, but didn't have the whole repository,
at least for these modules. I took the original xlibs CVS, imported that
to git and then merged the few X.org changes on top of that. For these
libraries, there were only a few very minor changes in X.org CVS.

> > There is a new git-cvsserver utility which is currently under
> > review (by lots of people) which would make these available via pserver
> > for anonymous CVS access. 
> 
> When?

The code is rather new; I'd like to see it bake awhile before attempting
to deploy it on fd.o

> I fail to see how unilaterally declaring development to be moved to a
> completely different revision control system fixes this in any way.

It's just frustration with how difficult CVS makes things; every thing
else uses the notion of global change sets in some fashion, as soon as
we get that captured from CVS, it seems sensible to retain our history
from that point in a competent SCM.

> Looking at
> http://gitweb.freedesktop.org/?p=xorg-lib-libX11;a=shortlog;h=f71ea0bc737c5a42e9e022b86e7ec3b4f846d31c;pg=1,
> I see the first commit of any importance to be 'Merging XORG-CURRENT
> into trunk', which is a neat condensation of several years of history.

I don't see this commit; Xlib commits at this point are about
stabilizing the XCB integration, which appears to be going reasonably
well.

> Yes, CVS is braindamaged, but git hasn't made any of this historical
> braindamage disappear,

Yes, it has -- a careful migration from CVS to git retains the history
and can patch around the damage caused by careless CVS usage. Once that
damage has been repaired, we're out of the per-file revision control
purgatory which is the source of most of our current ills.

> So, for a small win in being able to
> be more careless with branching and merging, we lose the familiarity of
> CVS -- I still have not seen any compelling 'this is how you manage your
> normal workflow with git' tutorials[0]

Then you haven't looked very hard; there are lots of those available on
the net, and I've given two presentations on precisely this topic, one
at a conference you attended.

>  -- we lose CVS pserver

git provides an anonymous repository synchronization service that
replicates the functionality of cvsup, and we should be able to provide
pserver in a few weeks once that code has stabilized a bit more.

> , we end up
> running a non-chrooted service that depends on the ability to invoke
> random other processes

we could chroot this with some work; as the service only provides read
access by design, it seems more secure than even chrooted pserver to me.

I'm also expecting it to move from a scripting language back to C at
some point, leaving us with only a single application to chroot.

>     * xlibs/*: the generally-accepted baseline until R7.

The goal is to get rid of this

>     * xorg/{proto,lib}/*: where development has happened, particularly
>       after repeated assertions that it would become the canonical tree
>       when R7 was released.

xorg should become the 'canonical' source for everything, but it will be
split across different revision control systems unless we choose to
either remain with CVS forever or switch every module at the same time.
Both of these seem like bad choices to me.

>     * git: this is the place where libX11 and the three new-ish
>       extensions live now, so I'm told.

Git is not a separate project, it's just a different SCM used on the
same project. As such, we need to remove the CVS repositories of these
modules from public view as they are migrated to a different SCM. For
myself, I don't care if every module in the system uses a different SCM.
I believe each module owner should be able to use tools they're most
comfortable with, as long as they get the work done. Having learned half
a dozen SCMs over the last year, it's really not that hard to figure
another one out and generate patches for it. Yes, I'd be happier if
everyone chose my favorite, but not enough happier to even consider some
community-wide global mandate.

> Particularly when there are significant concerns about the revision
> control system being chosen, which are generally handwaved away with
> 'well, moving to other revision control systems is painless' (it's not),
> and it's still alarmingly unclear which non-CVS system to use in future.

I haven't heard any concerns about using git aside from 'it's new', and
I'm confident enough in the system myself to dismiss those comments.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060305/73557c79/attachment.pgp>