The next LSB face-to-face meeting will be held June 1-2 in Boston, MA at the USENIX Annual Technical Conference '06.
This will be a two day meeting. Roughly, day one will be high level planning for LSB 3.2 and 4.0 and finalization of the roadmap for LSB 3.2, and day two will be lower level planning required to execute the plan constructed on day one (task assignment, timeline, etc.). Company/project representatives need only attend day one (though they may attend day two if desired as well). LSB workgroup participants should plan to attend both days.
The meeting will be held at the Boston Marriott Copley Place, the same venue as the USENIX conference:
Boston Marriott Copley Place
110 Huntington Avenue
Boston, MA 02116
Telephone: (617) 236-5800
Toll-free: (800) 228-9290
We will be in the Regis Suite on the third floor. Coffee, bagels, and muffins will be provided in the mornings and snacks in the afternoons; lunch will not be provided, though we're planning to find someplace offsite as a group.
For those unable to attend in person, we will have the conference line open for as much of the meeting as possible. The telephone numbers are 877-954-0722 (United States) and 203-566-1295 (International). The participant code is the same one we use for the regular workgroup calls--email firstname.lastname@example.org if you need it.
Day one will center around finalizing the roadmap for LSB 3.2 (Q2 2007) and looking ahead to LSB 4.0 (2008). We will also discuss other topics, including the LSB test suites, ISV outreach and upcoming developer programs. Roughly speaking, to be considered for inclusion in LSB 3.2, the interface must be present in the current generation of distros (e.g., RHEL 5, SLES 10, etc.) (or be a small enough increment to existing interfaces that it can be included in a service pack/update/etc.); and to be considered for inclusion in LSB 4.0, the interface must be present in the next generation of distros (e.g., RHEL 6, SLES 11, etc.). Obviously, the latter will require a fair bit of collaboration and advance planning, but it's a worthy goal and a necessary component to making the LSB less reactive and, thus, more useful to the ISV community.
|9:00am - 9:15am||Welcome and overview (Ian Murdock)|
|9:15am - 9:30am||LSB project organization and modularization (Ian Murdock)|
|9:30am - 10:45am||LSB 3.2 and 4.0: broad goals and feedback. What do the OSVs, ISVs, and upstreams want from LSB 3.2 and 4.0? How does/should the LSB add value? (Ian Murdock)|
|10:45am - 11:00am||Break|
|11:00am - 12:00pm|| Core (Nick Stoughton/Mats Wichmann)
|12:00pm - 1:00pm||Lunch|
|1:00pm - 2:15pm|| Desktop (Rajesh Banginwar)
|2:15pm - 2:45pm||Internationalization (Paul Gampe)|
|2:45pm - 3:00pm||Break|
|3:00pm - 3:30pm||Accessibility (Janina Sajka)|
|3:30pm - 4:00pm||Multimedia|
|4:00pm - 4:30pm||Printing (Till Kamppeter)|
|4:30pm - 5:00pm|| Other activities for 2006 (Ian Murdock)
Whereas LSB 3.1 stopped at the desktop toolkits (GTK and Qt), LSB 3.2 aims to "move up the stack" and incorporate more of GNOME and KDE. The low hanging fruit here are the freedesktop.org specifications, many of which are already widely adopted in the current generation of the major distros. Initial candidates for immediate inclusion appear to be:
Others? We should survey the major distros to see what other fd.o specifications are candidates for 3.2 and 4.0. We will also look at the fd.o Portland project. We are most interested in xdg-utils (i.e., the command line tools). We may also need to consider the desktop-file-utils package. Whether or not this work is a candidate for inclusion in the LSB depends on whether or not the major distros move to adopt it.
What will it take to provide backward compatibility across major versions of the standard (i.e., to guarantee LSB 3.1 applications will run on LSB 4.0 runtimes)? Is this even useful? Initial discussions indicate it makes the LSB more attractive to ISVs, as it would allow them to certify once and not need to recertify to later versions unless those later versions provide functionality their products require. However, it potentially imposes an additional burden on OSVs, as once an interface is present in the LSB, it would need to remain in the distros for a longer period of time to provide backward compatibility. Then again, don't the major distros provide backward compatibility guarantees of their own across major versions?
Different distributions ship slightly different versions of Perl and Python with slightly different selections of add-on modules, which complicates the portability of scripts across distributions. Can we standardize on a common subset? What about Java?
The title here may be a misnomer. The idea is about providing a common set of fonts across all LSB compliant desktops. Consider an OpenOffice document created on e.g. Ubuntu system, many times the document shows up on other distros in slightly different way (crossing page boundary etc) as the same set of fonts are not available or they do not display in the same way. Is it possible to define a common set of fonts that will be available on all platforms?
The LSB provides developers with an ABI/API portability layer but very little in the way of facilities to easily package applications that use it. Consequently, it is still commonplace for ISVs to distribute separate packages for each distribution they support, even different versions of the same distribution. Many ultimately give up and ship a tarball with an installation script of some sort. In addition, while the LSB provides guidance on what to do if an application requires interfaces not present in the LSB, it needs to make it easier to do the right thing in this case (e.g., statitically link or bundle dynamic libraries).
Can we do better around packaging? Specific ideas are:
Sometimes, when I’m trying out an unfamiliar open source component, I cheat. Even if the software I’m working on will deploy to Linux, I’ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.What can we do to help improve the state of affairs here? Projects such as autopackage attempt to improve the installation experience, but they interact poorly with the native package system. As above, how should such frameworks interact with the native package system of the underlying Linux distribution?
"The existing package managers (RPM, DPKG etc) are designed from distro point of view and not third party applications" (quote from Nat). This poses some interesting issues. We still like to integrate with the existing package managers as there are advantages to that.
Here are some additional requirements collected at the OSDL/DTL organized Desktop Architects Meeting at Mainz Germany:
What can we add to the LSB to help make printing "just work"? This can be divided into two high level parts:
As CUPS is a defacto standard in the Linux world, perhaps we should consider CUPS for LSB 3.2. Or perhaps we should consider OpenPrinting PAPI/JTAPI/etc. for LSB 4.0, which support CUPS and other printing systems. Note that the latter is only viable if CUPS supports PAPI etc. natively, which they have indicated they may be willing to do (Mike Sweet is a coauthor of the PAPI specification).
What's the plan to improve coverage of the LSB testsuites? How can we make it easier to test compliance of both runtime environments and applications and, ultimately, become certified? The LSB is an interface standard, and an interface standard is only as good as the testsuites that test those interfaces, so we absolutely have to do better here.
How do we make it as dead simple to develop to Linux as it is to develop to Windows? Roughly, this can be divided into two parts: better tools and better documentation.
Day two will be more of a traditional workgroup meeting, where the workgroup members put together the development plan for LSB 3.2.
|9:00am-9:15am||Summary of day one|
|9:15am-9:45am||LSB 3.1 postmortem and lessons learned|
|9:45am-10:15am||Release management and development processes: How LSB 3.2 will come together|
|10:15am - 10:45am||Systems and infrastructure (LSB database, regression testing, etc.): What can we automate/systematize?|
|10:45am - 11:00am||Break|
|11:00am - 12:00pm||LSB 3.2 task assignment, timeline, etc.|
|12:00pm - 1:00pm||Lunch|
|1:00pm - 2:00pm||LSB 3.2 task assignment, timeline, etc. (cont.)|
|2:00pm - 2:45pm||LSB 4.0: Can we get started on any tasks as optional modules for 3.2?|
|2:45pm - 3:00pm||Break|
|3:00pm - 4:00pm||Improving the LSB testsuites (the deep dive)|
|4:00pm - 4:30pm||The Developer Network: What's the plan for building a community maintained developer portal?|
|4:30pm - 5:00pm||Conclusion|
We have a hard limit of 30 participants. The following people have confirmed attendance:
Here is hotel/travel information: http://www.usenix.org/events/usenix06/hotel.html. Please mention Usenix when booking your hotel.
Members do not need to be registered for the Usenix conference to attend this meeting. It will be in a separate meeting area upstairs from the conference and will be listed as the LSB Workgroup Meeting. The conference room will have wireless Internet access.