Moving xlibs modules to xorg

[Daniel Stone]

On Sun, Mar 05, 2006 at 02:42:47PM -0800, Keith Packard wrote:
> 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:
> > > 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

The git server seems to be in the same state of random flux.  For some
reason, this fails to inspire confidence in me, for a system we've
apparently just started using to develop reasonably large swathes of our
infrastructure (libX11 is hardly small).

> > 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.

CVS does actually have a concept of this now, through the commitid tag.
AIUI, this is how most SCMs piece together CVS history for commits made
since the commitid tag was introduced (it's only when you go back past
commitid that you have to do the awful date-and-log hack).

> > 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.

My point was that git does not in any way fix our troubles with lack of
history.  It does not add the years of XFree86 history that we don't
have.  It merely changes the interface from ViewCVS to gitweb (which is
arguably an improvement, but that's irrelevant).

> > 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.

If you're hacking the repository anyway, you can just plumb in with rcs
and be done with it.

> > 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.

There's no concise git-in-two-minutes I can refer back to from that.

> >  -- 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.

So we lose CVS pserver for some arbitrary amount of time, still.

(Noting that the Arch imports were supposed to be done by OLS, and are
 still not done.  Modular X was supposed to be done in mid-2004.)

> > , 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.

While pserver is an abomination, we do run it in read-only mode (I
believe it was you that set this up originally).

> 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.

Sounds more and more like Arch as it goes along.

> >     * 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.

I agree.  It doesn't necessarily make anything else a good choice,
however.

> >     * 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.

I'm quite skeptical about how well this model will work in practice.

> > 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.

Then you haven't been reading the replies to your own mails, instead you
appear to have been, as you say, dismissing the comments.

I've had long discussions with you about git's abominable UI, several
times.  It truly is a disaster on a tla scale.  I don't believe concerns
about git's fundamentally broken[0] UI can, or should, be handwaved
away.

I'm happy you're confident in git's system.  I'm confident in darcs.
Other people are confident in
baz/bzr/mecurial/hg/monotone/darcs/rosegarden/whatever, too.  People are
confident in Fresco/Y/DirectFB.  I'm confident in running anoncvs on a
separate machine to our secure commit-only source server.

[0]: 'But someone else will build a wrapper around it in the grim
     meathook future' is a cop-out in UI design, not some kind of
     inspired masterstroke.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060306/de1bc87a/attachment.pgp>