[lfs-dev] A note on Xorg Updates
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
> 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
(Just my opinion - (although it happens to be correct in this case ;P ).)
More information about the lfs-dev