Don't blame LSB and standards, please: was: Re: Fedora Plasma Product, feedback please

[Christian Schaller]

----- Original Message -----
> From: "Jóhann B. Guðmundsson" <johannbg at gmail.com>
> To: "Fedora community advisory board" <advisory-board at lists.fedoraproject.org>, "lsb-discuss ML"
> <lsb-discuss at lists.linux-foundation.org>
> Sent: Monday, March 31, 2014 1:06:17 PM
> Subject: Re: Don't blame LSB and standards, please: was: Re: Fedora Plasma	Product, feedback please
> 
> 
> On 03/28/2014 04:21 PM, R P Herrold wrote:
> > On Fri, 28 Mar 2014, "Jóhann B. Guðmundsson" wrote:
> >
> >> ( what is weights and measures other then standards ) but that
> >> undesputable
> >> fact aside I dont see how the failure of LSB as an standard which boils
> >> down
> >> to it being drive/dominated by Red Hat and Novell/Suse and the lack of it
> >> being capable of keeping up with changes in the GNU/Linux ecosystem, can
> >> be
> >> applied to the work that is being done here or it being mapped one to one
> >> with
> >> that work.
> > Wearing my centos co-founder hat, I assure that there is no
> > 'domination' there, and I've been present for more than a
> > decade.  There formerly was some, when an addition of Java was
> > being pushed by some enterprise stakeholders [Sun was still
> > free-standing at that time], but that is ancient history by
> > now
> 
> 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

But this demonstrates why making standards like these are really hard.
Because you can either :
a) just standardize on what is already a standard, and thus making it likely your standard will be to 
underdefined to actually solve the problem space at hand.
b) Try to make some choices in your standard, but if the people not already following the
choice you made doesn't agree, the standard will not really be a standard, and you end up with the 
https://xkcd.com/927/ situation. 
c) Try to negotiate any standard by with as many stakeholders as possible up front, before making something
a standard. This is possible, but extremely time consuming and slow moving. Freedesktop is trying this
 in the desktop space. It works, but the results after quite a lot of years is still a fairly limited
set of standards. Thus bringing you back to the underdefined problem of a).

So while it sounds very poetic to suggest that the workstation effort should just 'define standards that
anyone can implement', it doesn't really work in practice. And even in the rare case where we would have
succeeded in defining a standard, we would in reality only have given our users a new collection of bugs
to deal with, bugs that depends on which of two functionality identical implementations they ended up with.

Christian




> > These days, there is just: participation.  As to 'keeping up',
> > the Fedora mantra of 'move fast, be willing to experiment and
> > break stuff' is scarcely something a standards track should
> > aspire to
> 
> Fast moving distributions as well as standalone applications and
> application stacks should be able to follow well defined standards.
> 
> If not that just highlights shortcomings of that standard not the
> distribution or the application or application stack.
> 
> > LSB starves from insufficient quantities of software
> > engineering talent.  Its processes are in all material
> > respects open, and based on free and open sources.  Anyone
> > with the inclination can play along.  A request for help gets
> > a thoughtful answer and pointer in under 24 hr (mailing list),
> > in under 8 hr (IRC), and in under a week (bug tracker triage).
> > Wiki rights are accessible with a mere registration to stop
> > spamming. We run an open weekly conferencall and minutes
> > result and cross our mailing list
> >
> > We lost one FTE about a year ago, and there is just not enough
> > horsepower.  We ran a all day (I had to leave after six hours)
> > planning event at the LF Collab summit, with G+ and dial
> > inaccess, all duly noticed on our mailing list, and a grand
> > total of 6 people participated
> 
> How do individuals join the standards committee?
> 
> > Canonical seems to look solely to Posix these days. Fedora
> > glances in our direction but does not seek LSB conformance
> > certification, nor materially participate in our effort to get
> > LSB 5 'out the door'.  Debian is so glacial and enjoys
> > flyspecking and squabbling (witness the recent 'systemd'
> > dustup and vote, that they don't participate much. The SUSE
> > enterprise product tests and participates; RHEL 7 will add a
> > new approach to conformance if the beta is any sign, and has
> > had a representative filing bugs with us.  Oracle treats the
> > OS as a foundation for its DB engine products, and does not
> > really need an LSB imprimatur to sell its product
> >
> > But it is like the child's story of _The Little Red Hen_ ...
> > all will eat the bread, but few really are willing to
> > participate in its preparation.  I can think of three people
> > continuously present, triaging, and working bugs.  That's it
> 
> 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.
> 
> 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.
> 
> >
> > Probably we (LSB.next, so to speak) made a mistaken design
> > choice to widen coverage at LSB 5 made two years ago, to chase
> > later libraries (gtk / qt), rather than narrowing scope to
> > core utility.  But that was what the ISVs and the certifying
> > entities said was needed then.  I hacked back that wiki's list
> > of deliverables, pretty ruthlessly over the past 9 months as
> > we have worked on the release (feature based, rather than time
> > boxed)
> >
> > I cannot think of a single third party open bug on 5 filed
> > after the first beta drop, and it is ready to go once we
> > complete the rest of our P1 items
> 
> 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.
> 
> JBG
> _______________________________________________
> advisory-board mailing list
> advisory-board at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board