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

[Matt Taggart <taggart at carmen dot fc dot hp dot com>]

Alan Cox writes...

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

True, compared to v6. It is the best practice when you also take into 
consideration non-gcc implementations though right? (last I heard, I don't 
actively track them so maybe someone can chime in here).

> 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

The spec is based on 3.3. Do you know of problems where they don't match?
Most of the runtime implementations are using 3.3.4 in their current 
shipping releases.

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

The v5 ABI is not perfect, but upstream is committed to maintaining the 3.3 
branch right? This branch has the advantage that it will be the last to use 
the v5 version.

> 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.
>
> It does not meet "distribution maintainers cooperative". 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.

We try to evaluate the criteria individually, these are really "upstream 
co-operative" complaints. The majority of distros are shipping the 3.3.4 
upstream version in their current releases, so they are sync'd up on 
version and co-operative.

> Since you clearly value the considerations listed I move that on all
> these basis C++ is struck from LSB 2.0 because it fails the LSB's own
> basic published criteria. 

Yes, before the existing c++ can be released these problems would need to 
be solved. The criteria are open to interpretation so there's some debate 
about what "solved" means :(

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

On the contrary, the LSB is attempting to reach consensus among the LSB 
runtime implementors (commercial and non-commercial). When existing LSB 
implementors were polled about this particular issue, 7 were willing to 
implement with v5, 1 preferred v6, and one had no opinion. It is thought 
that all could technically implement v5.

At different times the LSB has been accused of playing favorites by nearly 
all of the runtime implementors when they were the odd man out and 
something didn't go their way. So we must be doing something right :) We 
try to stick to stick to non-controversial stuff but cleaning up cases 
where one implementation is divergent from the rest is something the LSB is 
designed for.

> No agreement, no standard.

I guess the question is what level of consensus is enough? Is any level of 
objection enough to block adding something? If that was the case then FHS 
2.3 wouldn't be be added either (some didn't like /src and /media). It's 
probably a case by case thing, I don't know what the right answer is here.

> Its hard but its the long term win.

Yeah, I think we'll all prefer to wait but there are other (mostly 
non-technical) constraints.

1.) As part of the LSB application program nearly every ISV/developer 
that's been contacted has said that c++ is a requirement and won't look at 
the LSB/Linux until c++ is included. A lot of these ISVs are proprietary, 
but not all. Having more applications helps the adoption of Linux and Free 
Software, having c++ now speeds this up.

2.) The ISO PAS submission needs to happen before October.
 a.) there is a lot of value to having ISO certification since it
     can help Linux get into places it couldn't before like various
     governments, companies, and industries that require ISO
 b.) it can provide an advantage over non-ISO software. For example: a
     government might have a general policy to use ISO for something
     when it exists, but when it doesn't they can choose anything. So
     having an ISO certified Linux would mean in these cases they
     couldn't pick Microsoft anymore.
 c.) the PAS process opens a 6 month window for submittal which can be
     extended for 1 six month period. The PAS was applied for last
     October (when 2.0 was scheduled to release in January) and then
     extended, so the window closes this October. No one has ever missed
     their window before, but at the very least it would be a lot of
     paperwork to start the process over again.

So these non-technical constraints are increasing the pressure to release. 
One can argue if they are really worth not waiting for an ideal solution.

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

Yes, alienating the community would mean the LSB becoming non-relevant. I 
don't think anyone wants that.

So given the constraints does anyone have an alternative plan? What would 
it look like?

Thanks,

-- 
Matt Taggart        Linux and Open Source Lab
taggart@fc.hp.com   Hewlett-Packard