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

[Egbert Eich]

Keith Packard writes:
 > On Wed, 2006-04-19 at 10:40 +0200, Egbert Eich wrote:
 > 
 > > Everyone whose module if interest got switched is forced to do the switch.
 > > - and probably has to wiggle with two SCMs.
 > 
 > There is a big difference between using the code and modifying the code;
 > as long as we have concensus from the modifiers, I'm less concerned
 > about the people who are just pulling the latest revision as the
 > learning curve there is dramatically lower (git-clone vs cvs checkout).

True. But isn't the reason for git to make it easier for the modifiers?
I would think - leaving alone all the advanced features - in zeroes
approximation git can be used in a similar fashion even by the modifiers.

Everything else would create a huge barrier for new developers from other
worlds.

 > 
 > > So the learning curve is equally steep - it will just happen at different
 > > times for different people.
 > 
 > Precisely. This is a good thing, as we'll have people of varying
 > experience levels around to help out.
 > 
 > > Maybe we should find other ways of educating more people than pulling the
 > > rug from underneath them:
 > 
 > I don't know of a way to get people to spend the time other than to make
 > it compelling in some way. Eliminating their ability to contribute has
 > been shown to be a good motivating influence. Providing some lead time
 > to that may let them figure things out before it happens, but I suspect
 > most people will just wait until it's required before going off to study
 > the new system.

That may be true. But wouldn't having a sandbox help?

 > 
 > > - migrating a project that is of some interest but doesn't bring the	
 > >   world to a grinding halt when not updated.
 > 
 > For contributors, migrating their module, no matter how small, brings
 > their world to a halt.

Why's that?

 > 
 > > This would put the burdeon on the first one to make a small bugfix
 > > to migrate the module. 
 > 
 > Yes, and may prevent the bug fix from being applied for some time. The
 > alternative is to find a sucker to do all of the work themselves. ick.

I would not call a task force taking on this job 'suckers'.

 > 
 > > 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?
 > 
 > The migration tool is not the hard part at this point; it does need
 > documentation, but the usage is straightforward. Where the time lies is
 > in verifying that the results are sensible. Finding branchpoints in CVS
 > is hard, and the current tool doesn't get it right all of the time. Only
 > people with some level of experience with the code can verify the
 > branchpoints as reasonable. If you don't care that the git repository
 > accurately reflects the history of the project, then mass conversion is
 > possible. And, of course I'm going to keep working on the tool to make
 > the answers it gets better.

Right. I've dealt with these things and I'm still discovering
idiosyncrasies of CVS that make life miserable.

In the monolithic environment we have always added branches to the
entire tree.
However most modules have not received any patches inside their branches.
With a little knowledge how branching in CVS is done will however help
to discover which branches actually contained changes.

 > 
 > > Hm, maybe you want to comment why it is such a time consuming task to
 > > get people up to speed on the new SCM?
 > 
 > To commit changes to an SCM requires learning the internal model; I
 > haven't found an easier way to do this than to go and explain what I
 > know about the system. You could put together cookbook examples, but for
 > people making changes, I think that can cause problems down the line.

Well, it's the same with CVS. However when I first started using it
I just went by a cookbook and was was pleased that it was simple to
get into.
The same should be true for other SCMs.

 > 
 > > If it is really so hard don't we expect that this SCM will become an
 > > obstacle to new contributors?
 > 
 > One thing git does make easier is the direct application of patches, so
 > perhaps we'll develop a culture where minor contributions can be easily
 > integrated into the repository by an existing contributor so that new
 > contributors needn't learn the complexity of the whole system before
 > making any contributions.

Keith, you really scare me. Usually you downplay the complexity of things.
Here you actually make things look way more complicated than the tutorials
on GIT you can find on the web.

 > 
 > > You have forgotten some importand points:
 > > Make available *documentation *tools, put in place the infrastructure.
 > 
 > I only outlined the stages of the transition, not the elements required
 > for each stage. We've been slowly improving the documentation on the
 > wiki and will likely continue to do this as we learn new things.

Yeah.
 > 
 > > 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.
 > 
 > 'task force' == 'group of people with other things on their plates'.
 > 
 > I'm all for spreading the load in this kind of work, and having people
 > migrate their own modules will provide them with additional knowledge
 > about the system.

Well, we want to get done in time. If we force people to do this
themselves we may not arrive there in any finite amount of time.
We had the same discussion with modularization. 
Only there we didn't get started without a group taking on this
task. Here we may not get finished. 
This would be equally bad.

 > 
 > > If the release manager agrees to this and is willing to deal with
 > > two different SCMs during the release process this may be OK.
 > 
 > Ajax has already said he's planning on this for 7.1; there are already
 > several necessary modules residing in git.
 > 
 > >  > Assigning dates to the remaining steps would provide a complete roadmap
 > >  > for our completed transition.
 > > 
 > > Yes - a rather coarse grained transition plan ;-)
 > 
 > Refining the documented procedure as we approach each stage seems easier
 > than predicting how things will run at the start.

Sure, you always have to make adjustments along the way.
However without a clear goal in mind people will wander around.

Cheers,
	Egbert.