[SCM TRANSITION] Re: Proposal: move Randr protocol and library to git
Egbert Eich
eich at suse.de
Wed Apr 19 01:40:32 PDT 2006
Keith Packard writes:
> On Tue, 2006-04-18 at 17:03 -0400, Kevin E Martin wrote:
>
> 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.
Everyone whose module if interest got switched is forced to do the switch.
- and probably has to wiggle with two SCMs.
So the learning curve is equally steep - it will just happen at different
times for different people.
Maybe we should find other ways of educating more people than pulling the
rug from underneath them:
- migrating a project that is of some interest but doesn't bring the
world to a grinding halt when not updated.
rendercheck seems to be an excellent candidate here!
- creating a sandbox?
>
> 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.
This would put the burdeon on the first one to make a small bugfix
to migrate the module.
Isn't it better to leave this to people who have voluneered to devote
some time to learn how to do this right instead of making this somebody
chores with no experience and no interest to learn the process?
>
> > 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.
Hm, maybe you want to comment why it is such a time consuming task to
get people up to speed on the new SCM?
If it is really so hard don't we expect that this SCM will become an
obstacle to new contributors?
>
> 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
You have forgotten some importand points:
Make available *documentation *tools, put in place the infrastructure.
Some of this may have been done already but we should formualte success
criteria - pinning down what is considered essential for a successful
transition.
Also I would like to assign steps 4 to 8 to a task force rather
than making 4 - 6 the job of someone who has other things on his
plate.
>
> 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'.
If the release manager agrees to this and is willing to deal with
two different SCMs during the release process this may be OK.
>
> Assigning dates to the remaining steps would provide a complete roadmap
> for our completed transition.
Yes - a rather coarse grained transition plan ;-)
Cheers,
Egbert.
More information about the xorg
mailing list