Xlib moved to git

[Keith Packard]

On Sun, 2006-02-19 at 11:47 -0800, Stuart Kreitman wrote:
> Keith and all:
> 
> It does matter that we act as a COMMUNITY, and as you and many others 
> took part in the early
> conversations 3 years ago where we all shared the desire to build this 
> cohesive structure, it is
> difficult to understaned why one would risk making a unilateral decision 
> that affects so may.

I didn't choose to convert the X server, although I'm hoping to be able
to do that soon. 

Xlib is a very low-velocity project, selected at this time because we
had developed a concensus that a major change in the code was necessary
at this time (the integration of XCB support), and I wanted to ensure
that individual distributions could easily select whether they wanted to
build that new branch or the old one.

> The modularization effort in contrast was something that was debated for 
> a while, what turned
> out to be a reasonable length of time, as evidenced by the way the 
> modularization project work
> was performed by a good broad cross-section of people and delivered so 
> smoothly.

The modularization effort *did* affect everyone as everyone worked on
something affected by that change. In contrast, few people ever need (or
want) to change Xlib. As such, modularization required global concensus,
while switching one module should not. 
  
> So my question about all this is: If  the code management tool is 
> different for arbitrary modules,
> doesn't that contribute to the confusion and raise the barrier for 
> contributors to move among
> the parts of the system?

Yes. However, I think a wholesale conversion would be far worse;
different pieces of the system have different release plans and
different developer communities. I hope that each of these
micro-communities will decide to use the same (or at least compatible)
SCMS tools, but I don't believe we should migrate all at once, or that
we should even migrate the whole system. Pieces of our environment
change so slowly that we may never bother moving them from CVS.
  
> At the very least, we should have some public discussion about the tools 
> that are out there and
> let more opinions and experiences get expressed. Some of this has been 
> discussed, but not in
> any real detail afaik.

What I've learned is that you can't have public discussions about SCMS
tools that you haven't used; it's far to easy to poke holes in
particular aspects of a tool based on heresay. Informed discussions can
only occur once we have studied the tools in some detail.

I've been aware of many project migration plans away from CVS, and have
seen many of the (Gnome, most recently) make very poor choices purely
due to a lack of familarity with the tools.  

As I pointed out in my response to Alan, I do have reasons for selecting
git at this point. I also feel that it needn't be a permanent choice;
the key is that right now we have the ability to extract our repository
in all its glory to a change-set system; migrating to other systems in
the future will be far easier.
   
> > I'd like to know how pissed to get at this. Is he forking 
> > freedesktop.org  or just pushing the envelope?

As far as the code is concerned, I haven't made any changes to our
products that wern't based on extensive discussions. The Xlib migration
to GIT was pushed by the integration of XCB, something we've been
talking about for years and finally came to a strong concensus on at the
meeting in Santa Clara. 

I tried to carefully limit peoples expectations about the state of the
Xlib/XCB integration, and was quite surprised to hear just how eager
people were to get this out into the world and finish making it work.

Another area of strong concensus we reached at that meeting was in
naming maintainers of various modules and giving those people some level
of autonomy over their domains. I suggest that the development tools
used by each group are one area in which each module should be granted
autonomy.

Jim and I have often talked about 'draining the swamp'.  While not a
politically correct metaphor, it expresses the idea that individuals
working on the right small-scale improvements can collectively push the
whole system in positive directions. If you keep people from exploring
small improvements, you prevent significant global progress.  
 
> > Do you know if there are enough people like us out there to keep X.org 
> > alive in the event
> > of a  fork?

I think, instead, you should be excited to hear that someone is actively
exploring our long-term code management issues while maintaining Xlib
and working to solve some of the longstanding issues with supporting
multi-threaded X applications.

It's just a minor tool change here, for one tiny piece of our system.  

-- 
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/20060219/4b99d151/attachment.pgp>