[SCM TRANSITION] Re: Proposal: move Randr protocol and library to git
eich at suse.de
Tue Apr 18 09:21:11 PDT 2006
Luc Verhaegen writes:
> Maybe what Egbert is trying to say is: "Is git the official X.org SCM
> now?". This probably to get the matter settled once and for all.
Well, as there was little movement towards an alternative SCM
- other that some people assunmed that subversion would be the
natural choice - I assumed that there is some implicite consensus
(or an absense of strong opinions on other alternatives).
Looking at git myself I didn't think it's too bad a choice:
1. There seems to be a vibrant developers community behind it.
(other than CVS where I tried to file a patch with the bugtracker
and the only thing I ever got back was an auto reply that my message
was held for moderation).
2. Its syntax tries to be friendly to former cvs users and it looks
like a lot of effords are done to incorporate things that have
been useful about CVS.
3. It does offer a lot of features we all have been missing in CVS
for a long time.
There are some issues that people may consider drawbacks compared to
CVS, though. The most noticeable I came up with is:
GIT doesn't have version numbers (version numbers don't really make much
sense in the distributed development model of GIT). Therefore versions
of files cannot be identified by their version number.
Consequently GIT doesn't support auto editing files on checkout to
include an ID into a magic placeholder.
> There was a big flamewar when Keith did the xcb/libX11 push, so i'm not
> sure how accepted moving to git is. If it wasn't accepted, then i guess
> that the piecemeal moving to git is to make it an unavoidable fact,
> avoiding another timewasting row which ends in utter indecision.
Like it happend with modularization until someone stood up and made it
his job to guide the way.
> Egbert, i don't agree with everyone and everything having to move at the
> exact same time. Piecewise is the way to go here. We should just get
> "Yes, we're moving to git" out in the open, now, and then say "Should be
> done before 7.2 freeze", at which time the release managers (ajax)
> probably get to parsecvs the remainder (xedit). Running parsecvs is not
> a lot of work.
I'm not saying that it has to take place at one single date by flipping
a big switch.
What we need is
b. a road map
c. the commitment that people will take care that nothing is left
Since Keith has already demonstrated that migrating the biggest chunk
(the server) is doable and has the tools in place I don't think it will
be too hard to do and doesn't require nearly as much time as the
If we can reach consensus I'd even volunteer to make sure that all those
modules that are not actively maintained are moved.
I think it is importand that we don't end up in a situation where we
have a number of different SCMs and someone who wants to get snapshots
of our code base needs to study where to get them from first.
> The move to using git, even when being totally caught up in only CVS
> (like i was), isn't unovercomeable, and it's less painful and very much
> faster than modularisation. But it does require a small bit of effort
> from everyone instead of a lot of effort from a few.
Like with modularization a group with experience and devoted to the
process can easy transition for the individual module maintainer.
> 7.2 is at least 6m away, this is plenty of time for everyone to get
> superficially acquainted with git. And if 7.2 is considered too early,
> I'm sure that packagers and distributors are more easily able to cope
> with pulling code from both CVS and git, than every last developer
> adjusting their modus operandi from CVS to git.
Luc, that's actually not my only point. In the absense of a clear
consensus on where to go I fear that we might see people moving
to other SCMs for their modules.
However I feel if people have difficulties adopting to another
SCM whe should take their problems seriously and see if we cannot
fix them. I'm sure we will be able to accomodate everyone - except
maybe those who feel they are married to CVS.
More information about the xorg