[lfs-dev] A note on Xorg Updates

akhiezer lfs65 at cruziero.com
Sun Mar 10 09:41:00 PDT 2013

> From lfs-dev-bounces at linuxfromscratch.org Sun Mar 10 15:57:40 2013
> Date: Sun, 10 Mar 2013 16:50:53 +0100
> From: "Armin K." <krejzi at email.com>
> To: LFS Developers Mailinglist <lfs-dev at linuxfromscratch.org>
> Subject: [lfs-dev] A note on Xorg Updates
> Hi there,
> If you remember, we agreed not to upgrade Xorg components very often 
> some time ago.
> You can notice, however, that I sometimes bump a library, driver, server 
> and such for a newer version.
> The reason behind that is mainly that even upstream developers "agree" 
> that katamari releases are waste of time. So my thoughts are we 
> shouldn't wait for any major stuff to happen (like we did wait for Xorg 
> Server 1.13.0 because we didn't want to upgrade libraries and protocol 
> headers just because we agreed on that) and just upgrade things as they 
> get released - as other rolling release distros do.
> If you are interested, here is the link to upstream post
> http://lists.freedesktop.org/archives/xorg/2013-February/055493.html
> Probably the most important part is:
>      In keeping with the X.Org goal of about one release per
>      year, Release 7.7 of the X Window System occurred 6 June
>      2012. Release 7.6 was about 1.5 years earlier, in
>      December 2010. However, there is some feeling among the
>      developer community that the "katamari" point releases
>      of all of X are no longer terribly useful, yet are a big
>      consumer of developer resources. Thus, it is likely that
>      these releases will be farther apart in the future, or
>      will cease altogether--not because development pace is
>      decreasing, but because point releases of individual
>      components are a better mechanism in the "new" world of
>      modularized X development.

Well, you say '"agree"', whereas the doc uses the less-strong 'there is some 
feeling among the developer community'.

If they go down that route then are they relinquishing the responsibility for 
ensuring that a particular versioned set of components - e.g. a point-release - 
works well together (it reminds me of the fairly-recent 'tarballs are an 
obsolete concept' a year or so back): and instead are punting the 'problem' out 
into the world such that in practice distros will do that work. If so, then I'd 
expect contributors (of money and resources generally) - and funding is 
discussed at some length in the doc you linked to - to maybe take cogniscance of 
that and adjust accordingly: they'd essentially now be paying X.Org &c for 
components, but no longer paying X.Org &c for verified interoperability of the 
set of components.

Quite a lot of folks will not get involved closely in 'rolling release' 
projects. At some point, folks, a bit of coherence is appropriate: but I guess 
that release-engineering is deemed less attractive than "let's compile!" in 
some quarters. 

(Just my opinion - (although it happens to be correct in this case ;P ).)




More information about the lfs-dev mailing list