[lsb-discuss] Dropping architectures -- policy discussion

[Wichmann, Mats D]

On Wed, Nov 7, 2012 at 10:27 AM, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:

> > Suggestions to the wording of this "non-policy" are welcome. If anyone
> > wants to argue that we need to have a deprecation policy for hardware
> > architectures please speak up.
>
> Not sure why you need a deprecation as such. If someone can be bothered
> to do the work presumably its not deprecated, if nobody can be bothered
> then it is ? That also recognizes there may be platforms content to sit
> on old versions or to skip one.


I think that's basically right.  LSB hasn't had any luck with
"deprecation policy" anyway, because it says something about a
certain number of releases but LSB has never settled into any
kind of release cadence for it to make sense.  Pretty much as Alan
says, if someone does the work....

For those who are not insiders, the work after an architecture has
gone in generally only consists of generating new data to match new
LSB developments. So if a new library is added, or the spec for a
library is uplifted to a new version, it has to be validated on each
supported architecture.  This is, I think, where Robert's line about
availability of distributions comes in... if we're now using a C library
that matches glibc 2.15, and a particular architecture doesn't have
a distribution that runs that new a glibc, then checking that the
data (values, struct sizes, member offsets/alignments, support
for magical new ELF sections added by gcc/binutils, etc.) are
correct for that architecture, then you can't really "do the work",
even if the work itself is small - run a tool to gather the data, update
the database.

And the impetus for this is there may be as many as three current
architectures that don't really have a distribution (at least one that
aligns well with being an LSB target) any longer...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20121107/6d756ca3/attachment.html>