LSB Summit

From The Linux Foundation

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 imurdock@imurdock.com if you need it.

Agenda

Day one (June 1)

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.

**DRAFT schedule: June 1**
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) GCC 4.1 and libstdc++ v7 glibc 2.4 (NewGlibc) ISO, maintenance/errata (latter for non-core also) Language runtimes (Perl, Python, Java) Packaging
12:00pm - 1:00pm	Lunch
1:00pm - 2:15pm	Desktop (Rajesh Banginwar) Cross-desktop (GNOME/KDE) interoperability Font management Software installation and management
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) Improving the LSB testsuites Infrastruture improvements (LSB database, etc.) ISV outreach and developer programs

Cross-desktop (GNOME/KDE) interoperability

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.

Backward compatibility across major versions

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?

Language runtimes

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?

Accessibility

Pending ATK/ATSPI enhancements for Gnome 2.14, 2.16, and 2.18
X Keyboard ABI
ATK conformance tests
FSG Product Standards for Accessibility
Specify XComposite, XDamage, XFixes, XShape v1.1 (ShapeInput) for Magnification

Identity

OpenLDAP?

Kerberos?

Internationalization

Manageability

OpenLDAP ?

SNMP?

Zeroconf ? Avahi ?

Multimedia

ALSA ?

Xine / Xine-lib ?

GStreamer ?

Helix ?

libao?

Font Management

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?

Packaging

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:

Many ISVs want to use a single installer framework across all the platforms they support (e.g., using such products as InstallAnywhere). How should such frameworks interact with the native package system of the underlying Linux distribution?

It is too difficult to install applications on Linux compared to Windows. Jon Udell put it best here:
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?

Additional requirements for a Packaging tool

"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:

Easy to create – UI: Provide simple user interface to create a package
Easy to install – UI: Standard user interface during install time
Install location: User should be able to provide a base directory for installation.
License viewing capability at install time
Single object - one package installs everywhere
easy dependency resolution
capability for applications to provide updates/upgrades (like firefox): This is beyond just the tool to create a package; this is more infrastructure creating issues.
clean and complete uninstall (including all unused dependencies)
performance and memory footprint for small devices
Root access issues: This is an open problem that many have thought about
Mass installation capability: this potentially will require infrastructure updates.

Printing

What can we add to the LSB to help make printing "just work"? This can be divided into two high level parts:

Printer driver infrastructure: Can we standardize on an infrastructure for printer drivers such that printers work out of the box on any LSB conformant system, i.e. LSB certified runtime + certified (LSB?) driver = working printing system? The current practices here include CUPS, HPIJS, and OpenPrinting Vector.

Print dialog and related functionality for applications: For Qt based applications, print support is built in; GTK will not have that till 2.10 (LSB 3.1 standardizes on GTK 2.6). So, at least for the short term (till 2.10 becomes common practice, perhaps LSB 4.0 timeframe), we have a gap for GTK based applications.
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).

Security

Kerberos?

OpenSSL?

Virtualization

Improving the LSB testsuites

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.

Developer support

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.

Better tools: How can we improve the LSB SDK? Can we add an LSB package creation tool? Can we add plugins for KDevelop, Eclipse, and other IDEs that make it easy to build LSB conformant applications? Can we get the distros to bundle the tools, so distros can build LSB comformant applications out of the box in the developer configuration?

Better documentation: In general, Linux documentation is plentiful, but it's hard to find, and it's hard to separate the good from the bad once you find it. How can we aggregate the best of this documentation to make it easier to find, and how can we augment existing documentation where that's needed? How can we utilize the community to help us do this?

Day two (June 2)

Day two will be more of a traditional workgroup meeting, where the workgroup members put together the development plan for LSB 3.2.

**DRAFT schedule: June 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

Attendees

We have a hard limit of 30 participants. The following people have confirmed attendance:

Jeff Bailey (Ubuntu) (day two possible)
Rajesh Banginwar (Intel)
Stew Benedict (Mandriva)
Irina Boverman (Red Hat)
Alva Couch (Tufts/Usenix)
Todd Fujinaka (Intel)
Paul Gampe (Red Hat) (day one definite, day two possible)
Jon "maddog" Hall (Linux International) (day one only)
Marvin Heffler (IBM)
Till Kamppeter (Mandriva/FSG OpenPrinting)
Alexey Khoroshilov (linuxtesting.org)
Thorsten Kukuk (Novell)
Jeff Licquia (FSG)
Amanda McPherson (FSG) (day one only)
Ian Murdock (FSG)
John Palmieri (Red Hat/GNOME)
Markus Rex (Novell) (day one definite, day two possible)
Janina Sajka (FSG Accessibility) (day one only)
Robert Schweikert (ABAQUS)
Aaron Seigo (KDE)
Leon Shiman (multimedia)
Nick Stoughton (Usenix)
Kay Tate (IBM)
Ted Ts'o (IBM) (day one only)
Stephen Walli (Optaros) (day two only)
Greg Wright (RealNetworks)
TBD (CA)

Travel

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.