Re: "LSB 1.0"
The Architectural Review Board for OpenGL has a good model for this.
Everyone realizes that it isn't possible to prove an implementation of
OpenGL is fully conformant to the specification. There are too many
cases to test. Instead, people certify their OpenGL releases to a
particular OpenGL test suite that is controlled by the ARB. If the
binary passes the test suite, it is conformant - regardless of whether
or not it fails in any other case. The ARB has kept from getting "black
eyes", while still providing a useful metric for evaluation. The main
problem I believe they have not adequately addressed is over
simplification of the test suite. The historical trend in the real
world has been that companies try to weaken the test suite so that it is
easier to create products that pass the tests.
Can this model be applied to the LSB tests? There are obviously
different issues and problems to test, but the concept of a fixed list
of inputs with an acceptable range of outputs for each input can be
easily managed. It will be very difficult to have the tests get
progressively more strict, because companies will fight that trend in
order to maintain the badge of conformance with a minimum of effort.
That implies it would be prudent to start with a very complete test
suite, but that would take time to develop. One way to handle the
situation would be to pre-define a set of levels of conformance, but
only release the tests for the simplest level. The conformance rating
of 5.0, for example, might be something that we can all work to define
and encourage people to reach, but a 1.0 level would be acceptable in
today's environment.
Frank
Me wrote:
>
> Warning: this is marketing talk.
>
> > Personally, my feeling is that we should try to get 1.0 out as soon as
> > possible, but we should take the time to get the comformance/branding
> > program right, since that's going to be critical.
>
> "1.0".
>
> Herein lies one of my concerns.
>
> I claim that most people (even those who are intelligent
> and linux-savvy) will not naturally grok that a system that has
> "implemented LSB 1.0" isn't necessarily "LSB 1.0 compliant".
>
> In general, there is a critical branding distinction between a
> standard, which is a technical issue, and compliance to that
> standard, which is the main thing of public interest.
>
> Now, let's assume that no one is confused about the distinction
> between the standard and compliance to that standard. Further,
> let's say we have a distro that has passed the LSB 1.0 OS
> Compliance Test Suite and an app that has passed LSB 1.0
> App Compliance Test Suite...
>
> "get the comformance/branding program right"
>
> Herein lies another of my concerns.
>
> You talked about safeguards to try to ensure that the
> LSB doesn't get a compliance black eye.
>
> I am confident you will get a black eye.
>
> All it will need is one user to find one example where
> they think that one compliant app doesn't run on one
> officially compliant os, and bang, it will be news. It will
> be too late if the claim turns out to be false because it
> will make the possibiliy of non-compliance the news,
> and you can't quell that with "it can't happen".
>
> In other words, I am suggesting you build a pr strategy
> predicated on getting black eyes. Find a way to turn
> the black eyes into an advantage and you are golden.
>
> > The real problem is that we'd really like to have one press release
> > for the mainstream media ("the mundanes"), and another version for the
> > Linux community.
>
> Presuming Scott et al agree with this, here's an idea that might
> be practical. Have two events, with clearly distinct titles, and at
> least a calendar month between them. Then use the titles,
> keywords and other clues to appeal to one or other audience.
> Try to limit distribution to one or other audience. (Do you guys
> get broad distribution of your releases independent of distros
> and ISVs?)
>
> > Hmm.... perhaps an FAQ that helps to explain the scope of the LSB
> > would be helpful in this regard.
>
> I would think so. It strikes me as the right basic tool to enable
> informed individuals to help. One could drop in a single, credible
> link, or quote an individual QA. This would be both easier and
> more effective at dampening wild speculation than writing one's
> own posts. Indeed, if everyone and their dog is writing posts to
> explain what the LSB is or isn't, even good intentions could
> quickly turn in to a pr mess.
>
> --
> Ralph Mellor: http://www.dimp.com/ralphmellor.html 615.292.2917 x2
> If I had my life over, I'd study reincarnation. icq# 108597127
> --------------------------------------------------------------------
> Digital Impact: http://www.dimp.com/ 615.292.2917 or 877.DIMP.COM
> 2510 Essex Place, Nashville TN 37212 Fax: 615.269.9520
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
--
Frank LaMonica VA Linux Systems Inc. frankl@valinux.com
(512) 378-3003 (512) 378-3004 faxbegin:vcard
n:LaMonica;Frank
tel;fax:1 (512) 378-3004
tel;home:1 (512) 378-3003
tel;work:1 (512) 378-3003
x-mozilla-html:FALSE
org:VA Linux Systems Inc.;Professional Services
adr:;;114 South Prize Oaks Dr.;Cedar Park;TX;78613;USA
version:2.1
email;internet:frankl@valinux.com
x-mozilla-cpt:;26656
fn:Frank LaMonica
end:vcard
Reply to: