The Linux Foundation

 
RoadMap

From The Linux Foundation

Revision as of 20:40, 20 June 2006 by Mats (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

LSB Roadmap

The LSB Core Team has identified these areas as constituting a tentative roadmap through LSB 4.0 (2008 release). This is quite preliminary and it will be clear there's a lot that needs fleshing out.

Category "A"

These are clearly in the area of the LSB Core Team

  1. Maintain LSB Core and track evolution with ISO.
    Details 
    LSB does not plan to initiate major changes to lsb-core, but it needs to track changes to upstream projects and upstream specs. On the projects side, mainly glibc: there are features in glibc/kernel which will become mature enough to be ready for the specification. Areas being tracked include async I/O (a most-requested feature), message queues, and advanced threading interfaces. On the specification side, includes the POSIX spec (entering a revision cycle), and ELF and DWARF which badly need revision to reflect current practice, which has evolved beyond what's in current approved versions (LSB may need to help drive some of the ELF/DWARF evolution). It is also important that the core does not diverge too rapidly from an eventual ISO standard.
    Impacts 
    spec, tools, tests, examples
  2. Work towards submission of LSB C++ module as an ISO addendum.
    Details 
    the working plan, which has not changed, is to take the second release of lsb-c++ (which will come with LSB 3) and move that towards ISO. It's highly likely that this will involve considerable work on the base C++ ABI document (known as the Itanium C++ ABI, now actually used for all of the Linux architectures) as it's considered not complete enough to serve as a normative standard at the ISO level.
    Impacts 
    spec
  3. LSB Graphics module : update list of core X11 libraries.
    Details 
    The current list of X11 libraries is quite limited, new libraries have emerged as widespread "best practice" since the original X11 snapshot was taken, and these are needed an enablers for higher-level standards, particularly Desktop. There is also a set of small image libraries that are needed either in this module or in Desktop for the same reason (enablers). The final component of lsb-graphics is OpenGL, where the base specs have evolved and LSB needs to realign. Candidates include Xmuu (and maybe Xmu), libXcomposite, libXcursor, libXdamage, libXevie, libXfixes, libXi, libXinerama, libXpm, libXrender plus some combination of Xft, freetype, fontconfig for font handling. On the GL side, libglx, libGLU, libglut.
    Impacts 
    spec, tools, tests, examples
  4. Complete work on packaging specification / tests
    Details 
    A package install test exists in proof-of-concept form, needs to be turned into a real test. Spec needs more on how to install software not in rpm format. Format spec may need updating to match current practice.
    Impacts 
    spec, tests
  5. Improve LSB runtime testing coverage (currently ~10%)
    Details 
    LSB runtime testing coverage is currently ~10% of the total testable interfaces + commands. Major uncovered areas are curses interfaces, X window system tests (for anything besides the base X library), socket interfaces, remote procedure call interfaces, large file interfaces, OpenGL library interfaces, system commands, compression library, most of the C++ library, and a portion of the core libraries that do not have current tests.
    Impacts 
    tests
  6. Developing the missing test coverage could be something in excess of 75 man-years (based purley on the claims of how many man-years are in existing tests); the strategy clearly has to involve aquisitions and contributions and we don't have current data for the possibilities there. Some older notes were at TestSuiteExpansion.
  7. Better developer tools
    Details 
    a key challenge continues to be to make the LSB development process easy enough to not be an impediment. LSB has looked at better ways to build packages, improved checkers, better integration of LSB tools with popular build environments (e.g. Eclipse), etc.
    Impacts 
    tools
  8. 2nd Edition LSB Book
    Details 
    the LSB Book is the most accessible developer documentation, but due to time pressures, the application development portions are not well covered. In addition, although attempting to predict LSB 2, the book was essentially written against LSB 1.3, which will make it two major versions behind as of this fall. HP wants to drive this, waiting feedback whether there's HP buy-in (HP uses the same publisher as IBM press did for 1:e so it chould be a low-overhead thing to switch).
    Impacts 
    book - make sure tools are aligned with what book says

Category "B"

These are less clear in the roadmap as they will require much additional participation before they can move forward. The concept for new LSB modules is to have workgroups which include both topic experts and LSB process experts work on these; introduce them when they're ready to use; and then roll them up into the next applicable LSB Certification cycle (LSB 4 in this case)

Items in this category have many options on how and what to implement and thus are very hard to estimate resources for.

  1. LSB Desktop module
    Details 
    the most requested module, add enough of a baseline to make building desktop applications feasible. Anticipate working on core Gtk/Gnome libraries, and depending on ability to remove an IP-encumberance issue, the same for KDE.
    Impacts 
    spec, tools, tests, examples
  2. LSB Runtimes
    Details 
    the collection of languages which don't (usually) run native binaries but have some kind of a runtime environment platform are a big hot button: Java, Python, Perl, PHP. It remains uncertain what or how much LSB should do on this, but it's almost as frequently cited as Desktop as a key need; the IBM Chiphopper program specifically called out Python, Perl and PHP as essential functionality, and Java is mentioned all the time from the enterprise side. Java is the harder problem and the most requested; it's not certain if this is indeed a problem LSB/FSG can tackle.
    Impacts 
    spec, tools, tests, examples
  3. LSB Security module
    Details 
    many security-related features have been requested. Some which might fall in the LSB area (both scope and readiness) are capabilities and access control lists; ssl, ssh, Kerberos, possibly revisit PAM (PAM is in lsb-core but includes only the library/API, no information on how to produce PAM modules which might go here)
    Impacts 
    spec, tools, tests, examples
  4. LSB Manageability module
    Details 
    sysadmin and manageability has been excluded from LSB to date. A lot of this space is still seen as an area for distro differentiation, but there have been numerous requests in this area, and at the least we need to examine a few basic sysadmin enablers (like device mounting and unmounting), as well as SNMP, NIS/YP, and LDAP. LSB looks at enablers from an application viewpoint, so what we're thinking about here is what does a manageability application need.
    Impacts 
    spec, tools, tests, examples

RoadMap/Comments User Comments Include(RoadMap/Comments)


[Article] [Discussion] [View source] [History]