[lsb-discuss] Potential LSB Tasks

Dan Kohn 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  
test infrastructure)
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  
the fixes.

+ 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
Dan Kohn <mailto:dan at dankohn.com>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>

More information about the lsb-discuss mailing list