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

[Adam Jackson]

On Tuesday 18 April 2006 05:08, Egbert Eich wrote:
> 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.!).

You're insane.  Modularization was incredibly painful to do in one shot.  If 
we had any sense we'd have done it in at least two phases, probably by 
modularizing apps and extras first, then detangling the protocol headers such 
that the libs could be split out.  

Not that I proposed that initially or anything.

Refactoring a build system is no different from refactoring the code itself: 
you refactor, you don't rewrite.  But instead we rewrote, and just like every 
other major project that's tried that particular trick - cough, mozilla - it 
took us much longer to deliver than we anticipated and the product suffered 
in the meantime.

Learn from history.

I'm becoming of the opinion that factoring the drivers out is more pain than 
it's worth, but I probably only say this because of the next point:

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

Honestly, having just bumped every video driver to account for the new ABI, 
the marginal cost of having to do so over multiple SCMs is trivial compared 
to the base cost of having to do so for each of 60+ drivers.

This is because we modularised them out before the ABI was stable enough to 
expose.  Again: learn from history.

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

If this is ever the case (and it is), you're not releasing often enough.  
Wasn't "release early and often" the _mantra_ for modularization?

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

For all the modules that matter, I expect we'll see them all end up in one 
SCM.  If xedit never moves over to git, so what, no one likes xedit anyway.  
I'm not particularly concerned with timeframe for that, excluding the server 
where keeping it in CVS until 7.1 is a practical decision motivated by a) 
insufficient import tools, largely addressed by now, and b) allowing 
sufficient lead time for the developer pool to adjust.

I don't see any real benefit to doing them all at once, and I do see a lot of 
work with no one signed up to do it.  There's probably an argument to be made 
that doing them piecewise allows for a graceful transition time during which 
people can see the change coming, adjust to the new tools, and not completely 
lose their productivity in the process.

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

Historically, we haven't.  And even when we have, it hasn't worked very well.  
The only real heavyweight policy decision we the Foundation have made is 
modularisation, which took for god damned ever to get started [1], was only 
really completed due to concerted effort by a very small team, still hasn't 
been universally adopted by downstream vendors, and by being done in one step 
exposed tons of API and ABI fragility...

Contrast this with all the lightweight processes we've established pretty much 
by de-facto adoption (bugzilla triage guidelines, the [ANNOUNCE] convention, 
the 7.1 process, the MAINTAINERS file...).  Which work!

We _suck_ at process.

[1] - Remember when 6.7 was to be the last monolithic release?
http://lists.freedesktop.org/archives/release-wranglers/2004-March/000185.html
http://lists.freedesktop.org/archives/xorg/2004-August/002443.html
http://lists.freedesktop.org/archives/release-wranglers/2005-January/001694.html
You don't even need to read the messages, just look at the date stamps.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060418/c1a79d22/attachment.pgp>