[lsb-discuss] Potential LSB Tasks
dan at dankohn.com
Mon Mar 19 22:03:46 PDT 2007
With the shipment of LSB 3.1 Update 1, I'd like to propose a week or
two's effort to discuss prioritization for the next 6 months of LSB
spec and tool development. In short, the Linux Foundation has some
meaningful resources to apply to improving the LSB (including about
25 developers at the Russian Academy of Sciences (RAS), several full-
time in-house engineers, the current LF member companies who want to
see the LSB succeed, and of course the network of Linux professionals
who have built the LSB over the last 9 years). But we never have
enough resources for everything we want to do.
First, I'd like to create a fairly comprehensive list of everything
that we reasonably want to do this year. Then, I'd like to get the
key constituencies (particularly the RAS) to estimate the person
years and calendar time involved for tasks they are likely to carry
out. Finally, I'd like to make some hard choices on what we do and
don't have resources for. However, in your replies to this email,
please feel free to mix your answers to any and all of these
questions. And, of course, please add to the list of what we should
be doing. However, I really would like to focus on things that we
reasonably could get done in 2007 if we make them a priority, so that
this discussion doesn't become too abstract.
Here are some current todo lists:
LSB Test Todo (mostly small tasks that would clean up some of the
This page should be merged into the LSB Todo List.
Project Plan 3.2 (somewhat out-of-date view of what should be in 3.2)
LSB Futures Tracker (desperately out of date database)
We should either fix this or retire it
LSBTodoList (Small to large tasks that don't fit directly in the
release path, but would be great to have done anyway.)
Application Checker Enhancements
Here are some of the things we can do:
+ Improve Distribution Test Kit (DTK) Manager. Integrate into the
certification system. Make every error message a link to our wiki.
[Vladimir, what other enhancements is RAS considering?]
+ Create an Appllcation Test Kit (ATK) Manager. Create a
comprehensive tool usable by non-expert ISVs to evaluate and certify
their applications. Using similar code to the DTK Manager, create a
browser-based wrapper around appchk and pkgchk that provides user-
friendly errors. Also support asking the user to affirm certain
requirements of the spec that cannot be tested for. When the answers
come back all green, support uploading the logs to the certification
system. That is, the smarts of the certification system that
evaluate compliance can be offloaded to the client, which minimizes
what the server actually needs to do. Support a "post logs to the
list" feature to enable ISVs to get feedback when they encounter new
errors (like requiring interfaces missing from the LSB). Also,
support wiki integration so that ISVs can share with one another how
they've overcome porting issues (such as by statically compiling the
relevant functions from a non-LSB library).
+ DTK and ATK Manager wiki integration. Create namespaces in our
wiki so that reasonable default text is displayed (suggesting use of
the mailing list), but people can edit to describe their problems and
+ Super-lightweight Eclipse plugin, which is just the ATK Manager
downloaded through Eclipse and displayed on its internal web browser.
+ DB Navigator improvements. Easier to use, documentation on typical
use, and enable write interface.
+ Certification system, with all verification smarts built into DTK
and ATK managers.
+ Shallow testing vs. deep testing. [Vladimir, could you please
write up a few examples of how RAS is developing shallow and deep
tests for certain LSB interfaces, and share the information from the
original RAS proposal on the person days you expect to use per
+ Adding new libraries to LSB 3.2, like dBus and OpenSSL. Should LF
resources be doing this or will LF members do the work?
+ LSB stub libraries. Today, an LSB application will not run at all
on a distro that does not have LSB support installed, because it
cannot find the special LSB linker. Ian's idea is for the
application installer to detect this situation and install a stub
library that translates LSB calls to their underlying versions. This
will be a requirement if we want ISVs like Real to use the LSB as the
default (and hopefully only) environment to which they compile.
+ Write a new book for LSB 3.2. If we're going to do this, I believe
the majority of the book should be on how ISVs port to, test against,
and certify to the LSB, and how distros ensure LSB compliance. The
fact that the actual spec is in the back will make it useful, but I
think we need a lot more detail in the early chapters to make it
I look forward to beginning this discussion on the 8 AM call
tomorrow, and continuing it on the list.
Dan Kohn <mailto:dan at dankohn.com>
COO, The Linux Foundation <http://www.linux-foundation.org>
More information about the lsb-discuss