[lsb-discuss] Thoughts on LSB ISO standard

Carlos O'Donell carlos_odonell at mentor.com
Thu Jul 26 12:46:47 UTC 2012

On 7/25/2012 2:04 PM, keld at keldix.com wrote:
>>> Logistically, the sponsor of the LSB project, the Linux Foundation, became
>>> an ISO PAS submitter to facilitate the process.  It is my understanding
>>> that this status on behalf of LF has been allowed to lapse.  LF as a
>>> not for profit foundation was well positioned to sponsor the work, but
>>> the sponsors of LF itself have apparently lost interest in supporting
>>> the work of LSB as an ISO standard.  This is an outsider's viewpoint, I
>>> cannot presume to speak for Linux Foundation, but I believe it to be accurate.
> What I have heard is that LF lost their PAS submitter's status, as it was not renewed.
> I am not aware of LF's intentions on renewing their status, but we could
> investigate it. 
> There are other ways of proceeding if LF do not want to pursue it.
> 1. Every member body of ISO can take any specification and
> submut it as a fast-track. I am quite sure I can make Danish Standards
> do so. Danish Standards have done so before. 
> Also that procedure has been done recently for Ruby by the Japanese member body.
> 2. We could take LSB as a project in SC22.  This is how it is done by eg.
> POSIX, C and C++. We need either to have a Working Group in SC22, or
> some representatives from SC22 to LSB, as SC22 also do it for POSIX.
> 3. there are other possibilities, a bit more hairy and non-straightforward
> that could be investigated should the above possibilities not work out.
> The fast-track and the internal development each has its advantages and
> problems, and it also depends on the various parties to the process 
> which one to chose. I would say LF has the serving rights.
> I can elaborate on those alternate paths if you wish.

I was not aware that SC22 still has a POSIX WG? With the Austin Group
doing such a good job I thought that the POSIX WG was effectively disbanded.

I would support option #2 to create an LSB WG within SC22. This
might spur other members of SC22 to become involved in helping the LSB 
through the ISO process.

I agree with your final statement that the LSB needs to make a decision
here, but they can't easily make a choice without knowing exactly how 
much work is required by that choice.
>>> - LSB has often been criticised for not covering enough of Linux "common"
>>> functionality; since LSB-core is a subset of full LSB, that question should
>>> be even larger for whether LSB-core is actually useful as an ISO standard.
>>> At the same time, there has also been the very real debate about whether
>>> an LSB specification which includes "desktop" elements is an appropriate
>>> requirement for server-oriented installations of LSB.
> My personal opinion is that it would be good to also cover desktop elements.
> We do not need to follow POSIX scope. We are on top of POSIX anyway.

Wouldn't this mean that a server system, which doesn't have any desktop components
could never be LSB compliant?

I don't know how LSB 5.0 intends to solve the "multiple different certifications"
problem other than issuing multiple standards and certifying one system with
multiple standards.

>> Isn't this is a question that the LSB itself has to already answer for certification?
>> I would imagine that the ISO document would follow an already established answer.
> If the LSB standard already has an established scope including desktop,
> the the ISO version also should have that scope, IMHO.

I fully agree that the ISO version should have exactly what is in the LSB version,
but that isn't the question I'm asking.

>> For example the ISO LSB could be lsb-core, with all other functionality grouped
>> into optional Annexes.
>> Alternatively you could publish multiple documents one for each part of the LSB
>> and make them different standard. This is the approach taken by some of the
>> functional safety standards like 
> the 27000 series?

No, I was actually thinking of the IEC 61508 standards and how the core standard
is altered for each industry e.g. IEC 61511 (process), IEC 61513 (nuclear),
IEC 62061 (manufacturing) etc.

Where a central ISO LSB document could have additional documents each related to
a different sector e.g. servers, desktops, embedded.

It seems like LSB 5.0 reorganization intends to do something like this.

How do we organize this at the ISO level?
> yes, that would also be possible. But I would like LSB to be as consistent between 
> the versions as possible. Inconsistencies between versions will only confuse the marketplace.

I think you may have misunderstood my example because I failed to complete 
my sentence :-(

Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell at mentor.com
carlos at codesourcery.com
+1 (613) 963 1026

More information about the lsb-discuss mailing list