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

[Egbert Eich]

Adam Jackson writes:
 > 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.  

Yeah, but how does this invalidate my point? 
Doing it in one step or doing it in 2, 3 or 4 well defined stages still 
means following a grand plan and arrive a predefined goal within a certain 
timeframe. 
I don't see such a goal defined in our present SCM transition.

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

It adds another degree of freedom you have to account for if you want to
automate this process. 
You still need to touch a file in every driver. I've got a patch sitting 
here were I needed to do that too. But this is no different from before.

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

I think we are moving slightly of topic here - but: the ABI has been stable 
(modulo glitches) for 6 years. This sucked. Numerous problems we are facing 
today exist because of this paradigm. Decalring any ABI stable for such a long
period of time seems to be *insane*.

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

Well, before you do a release you still need some people to test your stuff -
don't you? The more there are the more secure you are that what you release
is really OK. 
Looks like you are advocating snapshot releases. Release and forget as soon
as the next one comes out.

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

Then we probably should have dropped it before modularization ;-)
Anyway, I don't expect that these modules will cause problems at all when
moving to another SCM: The number of commits that have gone in there have
been rather small (since our tree came into existence).

 > 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.
 > 
Right. However I would include the driver modules here also.


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

Sorry I don't see your point here:
If one of the modules you are intereseted in switches you have to switch.  
Or worse - you may have to deal with multiple SCMs.
There is no alternative. Commits to the old SCM should be explicietly 
prohibited.
So there is no transition period that allows you to adjust.

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

Right. But we have not been doing so badly. Noone argues that there is no
room for improvement. And the modularization process has really shown that
- no matter how painful - it can be done.

 > 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 

Well, it was the community (I hesitate to say the 'Foundation'). The
Foundation in the end blessed the appointment of a person who volunteered
to do it.
It's always the individual(s) who step up to take on the unrewarding chores
that makes the difference.

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

Well, downstream vendors have a much longer planning and preparation period
such that adopting the modular build was not within the timeline of their
current products. Futhermore there was the understanding that the first (.0)
release is not what would be recommended for shipping.

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

Indeed. You know why? Because:
a. make sense
b. try not to overburdeon
c. are willing to grant reasonable exceptions

 > 
 > We _suck_ at process.

Indeed. Nothing that can be improeved.

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

;-) I'm painfully aware of the history.

Cheers,
	Egbert.