Merge pull request #1 from rjschwei/initSetup

Getting things rolling for the "new" LSB

Two +1 votes, merging.

Author: rjschwei

Contributing.txt

@@ -0,0 +1,47 @@
+Contributing is easy, just fork the project on Github and send a pull-request
+when your changes are ready.
+
+The core technical team of the LSB working group will review the pull request
+and once agreement is reached (2 or more +1) the request will be merged. The
+core technical team with repository commit access will abide by the same rules,
+i.e. members with commit access will send pull requests to allow public review
+of proposed changes.
+
+The repository is structured into two major categories, documents and tests.
+The documents directory is structured to follow the work flow, problem
+statement -> proposed solution -> solution, the details are outlined below. The
+testing directory is structured to differentiate tests to their applicability,
+for example an interface test for glibc would be found in tests/glibc and
+tests that address distribution concerns, such as identifying the vendor are
+located in tests/distro. 
+
+documents/problems
+  - contains text files following the template (specification.tmpl) with
+    a completed Problem Statement section.
+  - the documents describe a problem that affects many or all distributions
+    and makes it difficult to treat the distributions as one platform from
+    an ISV developer or administrative point of view. Differences in packaging
+    generally do not fall into this category.
+
+documents/proposals
+  - contains text files following the template (specification.tmpl) with
+    a completed Problem Statement and a completed Proposed Solution section.
+  - the documents describe the proposed solution to the problem statement,
+    that will function as the starting point of a discussion in the respective
+    distribution development communities. Links to the mailing list discussions
+    are to be included.
+
+documents/specifications
+  - contains text files following the template (specification.tmpl) with
+    a completed Problem Statement and a completed Solution section.
+  - the documents describe the consensus solution to the problem statement.
+    In most cases the "Proposed Solution" section can be renamed to
+    "Solution". The links to the mailing list discussions during the proposal
+    phase are to remain.
+  - contains a list of distributions that have pledged to abide by this
+    specification and integrate the appropriate unit test into their QA suite
+  - contains the name(s) of the tests verifying the solution implementation.
+
+tests/distro
+  - contains tests that verify distribution level specifications, such as
+    the identification of the distribution vendor.

README.md

@@ -2,3 +2,68 @@ lsb
 ===
 
 Linux Standard Base Documentation and Tests
+
+The Linux Standard Base working group is a working group under the umbrella
+of the Linux Foundation.
+
+For many years the working group has spent it's 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 specification was defined as a trailing specification to document an
+accepted cross section of packages, libraries, and interfaces in Linux
+distributions, primarily focused on the Enterprise distributions. As the
+"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 the demand on new interfaces and 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 a tenable 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 it's
+work to become the place to discuss and resolve cross-distribution topics
+that are important to ISVs and distributors. This new approach 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 will be the last of it's 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, there is no ongoing work to produce a new LSB 5.1 or 6.0
+specification. 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. addition of interfaces, libraries,
+etc. is expected in the Bazaar repository.
+
+The focus on providing distribution compatibility, where its 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.
+
+The general work flow is that a problem is identified and the problem
+statement is formulated. The working copy of the problem statement is tracked
+in documents/problems. Once a solution statement has been formulated the
+document migrates from documents/problems to documents/proposals. The proposal
+should be vetted on distribution mailing lists and the discussion should be
+included by reference link to the archive in the proposal. After a consensus
+is reached and implementation can commence the proposal becomes a de facto
+standard and migrates to documents/specifications. 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. An accepted specification contains a list
+of distributions that have pledged to meet the specification and have pledged
+to integrate the appropriate test in their distribution test suite.
+
+Contribution guidelines are provided in the Contributing.txt file in the
+top level of the repository.
+
+
+

specification.tmpl

@@ -0,0 +1,43 @@
+LSB Specification
+
+Problem Statement:
+------------------
+
+Add the problem statement that affects multiple or all distributions here.
+Explain in detail how the observed problem negatively impacts ISVs or
+distributions by having divergent behavior between the distributions.
+
+
+(Proposed) Solution:
+--------------------
+
+Add a detailed description of the proposed solution in this section. Detailed
+implementation suggestions are welcome. Be as specific as possible to provide
+a good technical basis for discussion on the various distribution mailing
+lists.
+
+Solution Discussion Links:
+--------------------------
+
+Provide links to at least 3 distribution mailing lists where this topic has
+been discussed.
+
+
+Solution Rational:
+------------------
+
+Provide a brief description how the documented solution was derived.
+
+
+Distributions Support:
+----------------------
+
+A list of distributions that have pledged to adhere to this specification and
+integrate the test into their QA suite.
+
+
+Verification Test:
+------------------
+
+The list of tests that can be incorporated into distribution QA testing
+frameworks.