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

[Egbert Eich]

Keith Packard writes:
 > I'm doing some experimentation to extend RandR for xinerama (well,
 > shared fb) support. As such, I'd like to move the protocol and library
 > modules from CVS to git.
 > 
 > Without dissent, I'll move them in the next day or so.
 > 

Keith,

I'm a little unhappy about these piecemeal effords to move individual
modules of the X.Org code base to another SCM.

Don't get me wrong: moving away from the aging CVS does seem to be the
right thing to do - especially since feasable alternatives have become
available.

However  I feel that this should be done in one consolidated efford 
with the clear goal in mind to have all pieces available in the same 
SCM once the process is completed like it happend in the modularization
effords (thanks to Kevin at al.!).
Anything else bears the risk that the number of SCMs used on our code 
base starts to proliferate. 

I would prefer to not see this happening:

- Certain tasks may require to touch numerous modules at once:
  As an example: Enhancing the driver API would call for updating all
  the drivers (that are maintained in the X.Org project) to take 
  advantage of new API. 
  Even if this is a task that could be left to the individual driver
  maintainer, it may be preferrable if the person who designed the
  API performed this step. Having different SCMs for different modules
  will make this task more cumbersome.

- To take advantage of a new and improved API a user may have to
  upgrade numerous modules at once.
  Even if ordinary users are expected to pick released tarballs for
  this early adoperts and people interested in testing new features
  still need to draw code directly from the SCM.
  Providing a uniform SCM interface to the people will thus help to
  give our code better testing.

- Distribution maintainers: Recently someone metioned here that distro
  maintainers are mostly interested in stable and released tarballs of 
  the individual modules and thus generally don't rely on SCMs.
  This is true not really true: while distro maintainers very
  much perfer to use code for their releases that is considered stable 
  and well tested by the upstream maintainer - and blessed as such -
  they will frequently have to cherry pick and backport individual 
  patches to fix known problems in newly to be released products and 
  products that are under maintenance.
  Reducing the number of different SCMs used for different modules will
  help to ease this task.

I'm sure this list can be extended and there are more aspects speaking
in favor of coming to a consensus and moving towards a single SCM again.

The great benefit of a project like X.Org is that it allows to agree
on and establish a set of common standards, guidelines and procedures.
We should take advantage of this.

Cheers,
	Egbert.