[SCM TRANSITION] Re: Proposal: move Randr protocol and library to git

Keith Packard keithp at keithp.com
Tue Apr 18 18:14:36 PDT 2006


On Tue, 2006-04-18 at 17:03 -0400, Kevin E Martin wrote:

> The next question is: how -- all-at-once or piecemeal?  I took the lead
> on the modularization effort, wrote a plan for how to make it happen
> all-at-once, convinced enough people to help me execute that plan and
> then worked really hard to make it all happen.  If someone steps forward
> to take the lead for this SCM transition, then they will have the
> opportunity do the same -- this is just how our developer community
> works.  However, if no one steps forward to lead, then I expect that by
> default the transition will happen piecemeal.

I don't see any particular reason to try and make a massive switch; yes,
it complicates module checkouts in the meantime, but it also means that
a few new people learn how to navigate the system with each module,
providing some valuable mentor opportunities for everyone.

What does seem key is to have a basic plan to proceed with the migration
and execute things as people have time and interest. With a katamari
release, modules which don't change shouldn't need to be migrated right
a way; the tarballs from the last release should suffice. What we can do
is say that anyone interested in making a change after a certain date
must ensure that the module is migrated so that we can assure users that
everthing is either a tarball or in git.

> My hope is that there is enough interest in the transition that it can
> be completed in time for the first 7.2 RC, but I have not done any of
> the conversion work so far, so I don't have data to back up that hope.
> Perhaps Keith can comment on whether or not it seems feasible.

Yes, this is quite do-able, the conversion process takes only a few
minutes per module. The main reason for proceeding slowly at this point
is purely an educational bandwidth one; I've spent a lot of time with
each new user, and I don't expect that requirement to go away.
Incrementally, we can spread the teaching load out and ensure that
everyone involved gets proper indoctrination.

Whether we commit to migrating all of the modules en-masse or letting
them sit until changes are needed is a separate issue; I'd say that we
provide several steps along the way:

 1) All in CVS
 2) A couple of modules are transitioned by willing volunteers
 3) Modules are transitioned as desired by maintainers
 4) Modules must be transitioned before major changes are committed
 5) Any module getting updated for a release must be transitioned
 6) A module must be transitioned before any commits are made
 7) Unchanging modules may be transitioned
 8) Unchanging modules must be transitioned

I'd say we're in step 3) at this point, and I'd like to let people
continue to transition modules which have concensus among active
developers, even as we approach 7.1. There is minimal risk for a
transition; nothing changes in the active content, and the release
remains a simple 'make distcheck'.

Assigning dates to the remaining steps would provide a complete roadmap
for our completed transition.

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


More information about the xorg mailing list