Re: [Lsb-wg] opposition to LSB 2.0 rc1

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 29 Jul 2004, Alan Cox wrote:

> On Iau, 2004-07-29 at 22:05, anderson@freestandards.org wrote:
> > It would not be possible to release an LSB aligned with gcc 3.4 at this
> > time as it does not meet the rest of our release criteria, which can be
> > found on our website at http://www.linuxbase.org/futures/criteria/index.html.
> 
> That strikes me as funny to say the least. The ficticious kind of gcc
> 3.3 ABI currently proposed also fails the published criteria

Even if this is true, 3.4 has all the same problems, _additionally_ to not 
being deployed widely.

> It is not "best practice" as is clear from looking at the glibc/g++
> team view

I believe "best practice" refers to how often it is used in the world, 
which does often not correspond to what is the newest release.

> It is not a "stable ABI" - nothing implements it, and there is no
> guarantee a gcc 3.3.5 will ever be releases that does

Same can be said about 3.4 (it also had its ABI fixes, additionally IIRC 
also 3.5 already had changed the ABI in one corner case (but default uses 
the old way?  I don't remember exactly)).

> It does not meet "upstream co-operative". Upstream considers it a dead
> end failure path never having published a release using the proposed
> ABI.

That LSB was sort of standardizing without involvement of the GCC 
maintainers is indeed a problem.  But it gives no input to the "3.3 or 3.4 
problem".  And I think this situation improved somewhat (LSB: please 
remember this!).

> It does not meet "component versions". Upstream considers it a dead end
> failure path and has moved on to an incompatible ABI never having
> published a release using the proposed ABI.

Same as above.

> It does not meet "distribution maintainers cooperative".

I think, that's a flawed interpretation of yours.  The maintainers might 
not be happy, but they are not uncooperative.  In fact there is a 
difference between "distribution maintainers" and "GCC maintainers".  
Often those are the same persons, but with different hats.  As 
distribution maintainer one might be even more cooperative than as GCC 
developer.

> It's time the LSB stops being a vendor lapdog and remembers that its
> purpose is to standardise things in agreement with the community.

Which community exactly?  There are different ones, with different wishes
and goals.  There are at least three communities with incompatible goals
(standardizing 3.3 vs. standardizing 3.4 vs. standardizing the current
release).  One could only finally "solve" this by either not including C++
at all in LSB (thus alienating _all_ communities), or including the union
of all wishes (thus alienating all people who actually want to use the
standard for work, because of it's size then).  Short of these extremes
(which nobody wants IMHO) I think complete agreement is impossible to
reach.  There are only compromises.

> No agreement, no standard. Its hard but its the long term win. For all
> the talk of LSB 3 and fixing it, with no help from the community the
> current spec seeks to override there will be no LSB 3 because the
> community will have to do its standardisation without the LSB so that it
> can get technically sound results.

There would be no point in that, as it already exists.  We _have_ a C++
ABI defined, and a libstdc++ API.  There is nothing more to do on the
technical side (except improvements of course).  Everything more includes
politics, which then as well can be done inside the LSB.


Ciao,
Michael.