Linux Standard Base Documentation and Tests
The Linux Standard Base working group is a working group presently under the umbrella of the Linux Foundation.
For many years the working group has spent its time focusing on the production of the LSB specification which consists of a formal written specification, similar to IEEE or ISO standards, and an accompanying test suite. The test suite was focused on certification testing of distributions and as such had an easy to use LSB specific test framework.
The specification was historically defined as a 'trailing' specification to document an accepted cross section of packages, libraries, and interfaces in Linux distributions. Linux distribution development happens at various rates ranging from a 6 month release cycle at the short end to multi year release cycles at the long end of the time scale. Distributions with the longer release cycle are generally more interested in long term stability and as such had become the primary target of the LSB specification.
As the commercial "Linux market" has matured the specification and tests have contributed to maintaining a certain compatibility across Linux distributions making it reasonably straight forward for ISVs to treat many distributions as one Linux platform. At the same time with the market acceptance and adoption of Open Source software, Agile rapid development models, and Test Driven Design, a demand has appeared for new interfaces. The speed at which these interfaces have been adopted by Linux distributions has significantly increased such that the creation of a formal specification and accompanying certification is no longer as important a primary goal.
Therefore, at the face to face meeting held during the Linux Foundation Collaboration Summit in March, 2014, the working group has concluded that rather than producing a voluminous specification, the working group should transform its work to emphasize its other role as a neutral venue to discuss and resolve cross-distribution topics that are important to ISVs and distributors. This new focus will allow the working group to continue to provide the value of contributing to distribution compatibility while at the same time being more involved in cross-distribution discussions.
The LSB 5.0 specification released in 2014 may well be the last of its kind. The specification and tests are in maintenance mode. Bugs will be accepted and fixed and these bug fixes may be released as updates, i.e. 5.0.1 and others as needed. However, we do not presently plan to work new major LSB specification releases such as LSB 5.1 or 6.0. The specification and accompanying tests remain in the Bazaar tree ( http://bzr.linuxfoundation.org/loggerhead/lsb/ ) maintained by the working group. No new development, i.e. large scale addition of new interfaces, libraries, etc., is expected in the Bazaar repository. That repository will be quiesced as to new commits, and parts may be replicated to the GitHub Linux Standard Base project.
The focus on providing distribution compatibility, where it matters to distributions, ISVs, and other stakeholders will remain a key goal of the working group. The approach to the compatibility challenge is that a specific challenge will be described in a reasonably short document along with a solution. Once a solution is accepted by a number of distributions it becomes a de facto standard. Where ever possible one or more tests are to be implemented that allow distributions to test their compliance to the agreed upon specification. Distributions that pledge to support the agreed upon solution are listed in the document containing the problem statement and agreed upon solution.
The general work flow is that a problem is identified and the problem statement is formulated. The problem identification generally happens via the issue tracker in GitHub. Once a problem statement is formulated a pull request for the document located in documents/wip should be issued. A second step is the creation of a solution proposal which may then be solicited to distributions for discussion. Once consensus is reached the solution is committed to documents/specifications without additional changes. Changes to accepted solutions should only consist of trivial fixes for spelling and grammar as well as additions of new distributions pledging to support a given specification.
The solicitation of a Problem Statement or a Solution Proposal should occur on a distribution public mailing list and a link to the thread should be included in the document.
Unless specifically stated no document should become an accepted specification without an accompanying test that allows distributions to self monitor their compliance to the agreed upon de facto standard.
Contribution guidelines are provided in the Contributing.txt file in the top level of the repository.