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

[Keith Packard]

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).

> 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.

> - 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

-- 
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/20060419/c64cbd51/attachment.pgp>