This is a page describing the LSB 5.0 project.
Work on LSB releases is tracked through a combination of bugs and wiki pages. Smaller tasks should have at least a bugzilla entry while larger tasks should have both a bug and a wiki page. Compound tasks should use "rollup" bugs, which are blocked by the collection of different components (use the keyword rollup). Note the LSB bugzilla doesn't clearly differentiate between feature requests and bugs, but developers rarely have trouble keeping track. Resources - be they bugs, other wiki pages, etc. - should be linked in on this page, and completed tasks should be marked as done (not removed). Keeping everything linked together by way of cascasing bugs makes it much easier to track everything that's been done for writing release notes and other commentary on the release. Indeed, the the rollup bug for the overall LSB 5.0 release is bug 3164 and it references rollup bugs for major areas of the release, such as Software Development Kit, Specification, etc. It is also useful to search for bugs by using the Target (or Target Milestone) value of 5.0.
So this isn't really a conventional "project plan", it's more a fluid/evolving list of things that are going on, a bit like a whiteboard where things get added, crossed out, and occasionally completely rewritten as conditions change. Eventually, it will firm up and mostly just get status updates, but do consider that for large parts of the development cycle this page may be highly changeable and don't go quote this as "The LSB promised...".
NOTE: at one time, before the LSB F2F Spring 2011, the release following LSB 4.1 was called "LSB 4.2". Many references to "LSB 4.2" may still exist. These should be interpreted to refer to LSB 5.0 at an early stage.
|Modularize the standard||Confirmed Objective||See the Modularization50 page for more in-depth information. In the LSB call on 2012-02-08 we decided that modularization is an objective for 5.0. Discussion about the proposal is to commence in another call.|
|Modularize the tests||Confirmed Objective||At present it is difficult to introduce the LSB tests into a distribution QA suite, such as the OpenQA, as the suite is a rather large chunk of tests. Having tests either by module (related to modularization topic) or by library eases introduction of LSB tests into distribution testing. This then also shows the value the LSB can provide.|
|Interface uplifts and deprecations||Confirmed Objective||See Uplift_Target for details about the uplifts being considered.|
|Addition of new modules and/or trial use modules||Confirmed Objective||Major changes are occuring in the distributions, systemd and the merge of files into the /usr tree are projects underway in a number of distributions. The systemd implementation has effects on the LSB, the filesystem merge has effects on the FHS.|
|Debate and resolve the modularization question||Completed||In the meeting on 2012-02-22 we agreed that the way forward with modularization is to expose modules and potentially submodules. The "runtime" build profile targeting is orthogonal to modularization and is considered a potentially nice to have tool chain implementation.||2012-04-25|
|Create an initial draft for a modularization implementation specification||Completed||Draft to be completed by Robert. The draft should contain architecture for modules to be exposed and discuss how tools will present the modules to the user (application developer). The high level guideline for the draft is the existing modularization proposal. Initial draft completed 2012-03-29.||2012-04-03|
|Discuss modularization design and finalize||Completed||Robert to merge current arguments of lsb_release with current proposal as discussed at F2F. Post to mailing list when updated. Complete by 2012-04-10||2012-05-02|
|Implement the modularization of LSB as designed||In progress||Bug 3508, Task List|
|Provide documentation of current status.||Completed|| We need a document that describes the current status of the test infrastructure, including a graph of the test work flow. from this we can determine where we have opportunities to break things apart and how we can automate individual test modules to facilitate easier upstream integration.
See TestStatus50 (WIP)
|Develop a test modularization proposal||In progress||Based on the information gathered by the test status documentation we can develop a proposal to split the test suite into digestible chunks. However, the modularization design has a potential impact on this design, thus we want to wait until we at least have a tentative agreement on the modularization design.||2012-05-17|
|Debate test modularization proposal(s) and decide a direction for the project to proceed. The outcome of this discussion determines whether or not this is an object for the next release.||Not started||2012-05-30|
|Complete the table on the Uplift_Target page with time estimates for the work to be done||Not started||We need to estimate the time it takes to implement the proposed uplifts in order to get an idea how long our release cycle will be.||2012-07-25|
|Debate the proposed deprecations and decide what, if anything will be deprecated||Not started||Proposed deprecations are listed on the Uplift_Target page||2012-06-27|
|Debate potential new modules need to be added to the LSB||Not started||Proposed additions are listed on the Uplift_Target page||2012-05-30|
|Debate potential trial use modules for the next version of the LSB||Not started||Proposed additions are listed on the Uplift_Target page||2012-05-30|
In previous releases the LSB oriented itself toward "current" so-called enterprise distributions. This caused the LSB to be far behind the state of the art due to the long live cycle of these enterprise distributions. While the enterprise distributions are the basis for the primary target "customers" of the LSB, third party software developers, it has been learned that the enterprise distributions do not re-certify a given release series to a newer LSB release. Therefore, the previous practice that caused the LSB to trail very far behind the leading edge will be abandoned for the next LSB release. This was a decision reached at the LSB F2F Spring 2011 meeting. For this next release the target is to strike a middle ground between "chasing" ever evolving community distributions, anticipating potential technology expected in the next enterprise distributions, and trying to make reasonable judgments about needs of the target "customers".
Prior to setting a release date for the next LSB release, LSB 5.0 decisions need to be made about the objectives for the release, see Potential Release Objectives above. After the objectives have been determined high level tasks per objective must be outlined and time estimates must be created.
A list of random tasks and comments that were previously listed on this page but are not necessarily related to the next release. Parkinglot50