[lsb-discuss] Don't blame LSB and standards, please: was: Re: Fedora Plasma Product, feedback please

"Jóhann B. Guðmundsson" johannbg at gmail.com
Mon Mar 31 17:21:10 UTC 2014

On 03/31/2014 03:34 PM, Jeff Licquia wrote:
> On 03/31/2014 07:06 AM, "Jóhann B. Guðmundsson" wrote:
>> Last time I check and from dawn of time the LSB standard required
>> application to be packaged in RPM format which immediately excludes
>> distributions that do not use RPM as their default/preferred package
>> manager
> This is not correct.  LSB applications may be packaged in a number of
> ways

As far as I know only two either by using rpm or by using lsbinstall ( 
which has it's own set of problems ) and it's bit odd is it not, for 
standard to be providing it's own installer let alone be providing two 
options when that said standards sole existence is to eliminate 
fragmentation ( so it should either be providing only one method of 
doing things or none at all ).

> By participating:
> http://www.linuxfoundation.org/collaborate/workgroups/lsb/contributing
>> This highlights the fact that the joining process might be to
>> complicated or lack of buy in from distribution and application
>> developers due to the standards not being maintained/defined well enough.
> I don't believe *joining* is that complicated; we take on any comers.
> There is a bit of a learning curve, though, which we are working on
> addressing, and that probably contributes to the difficulty people have
> with participating in a meaningful fashion.
> Another possible factor is that standards work isn't very "sexy", and
> involves a lot of things that the free software community hasn't been as
> good at in the past--documentation, testing, etc.

People are working on standardizing things outside the so called 
standard itself so the man power and will to do so is not the problem here.

>> Why should an application or distribution strive to follow and meet
>> those standards when they are not in the buisness of selling or
>> supporting that distribution, application or application stack since to
>> me that standard has always seemed to be more written to favoring those
>> that make profit out of GNU/Linux ( Red Hat/Novel etc) and related
>> software rather than being focused on standardization/unification in the
>> GNU/Linux ecosystem.
> I'm sorry you have that perception.  We try to be strictly neutral
> regarding distributions, and one of the goals in our most recent efforts
> is explicitly to more aggressively target the community distributions.

Try being a keyword here.

>> Few bugs open does not mean that standard is well written it might just
>> as well mean nobody is following/using thus have faith in it and the
>> fragmentation in the GNU/Linux ecosystem itself is evidence enough that
>> LSB is failing as standardization body since it does not solve the
>> problems it initially was created to solve.
> Do you have concrete suggestions for how to solve those problems?

Here's a concrete slab on top of my head head LSB could try to to follow 
, to restore faith in LSB as in ....

A)  Stop expecting people reaching out to you but start *reaching out* 
to application developers distribution and their community.

B)  Explain to them what the benefits of standardization is and how it 
can be used to achieve their aims.

C)  Listen and work with developers, distribution and community's 
working out issues and reach consensus what said standard should be.

D)  Help them building policies, regulations and other frameworks that 
support the standards within their community's.

E)  *Monitor* progress of distribution and application developers 
implementing and following said standards.

F)   Break into parts the process of defining the standard as in involve 
the involved developers in the specific area in the part of the 
standards being defined.
       In other words there are no individuals that are seasoned enough 
or possess the engineering talent to be able to cover all sections of 
the standard

G)   Hold workshops with the individuals that are tasked with defining 
parts of the standards, policies, regulations and other frameworks that 
support that standard.


More information about the lsb-discuss mailing list