LSB face-to-face (December 2006)
The date of the next LSB face-to-face and the first FSG Packaging Summit is now set: December 4-6, 2006. SAP will be providing facilities for the meeting at the SAP office in Berlin, Germany.
This will be a three day meeting. The first two days (Monday, December 4 and Tuesday, December 5) will be the LSB face-to-face meeting. The primary agenda will be to finalize the LSB 3.2 roadmap and timeline.
Wednesday, December 6 will be the first FSG Packaging Summit. The goal of the Summit is to bring together the key people in the Linux packaging world and ISVs to discuss the future of Linux packaging. Topics will include RPM, the role of other packaging technologies (dpkg, APT, yum, etc.), and the needs of ISVs in packaging solutions.
LSB face-to-face, day one (December 4)
Day one will focus on current status and recent progress at the LSB; a high level discussion of goals and priorities; feedback from the Linux platform stakeholders; and project infrastructure and deliverables, including the new LSB database and testing framework, tools, documentation, and developer network.
|9:00am - 9:15am||Welcome, introductions, and overview of day one (Ian Murdock)|
|9:15am - 10:00am|| LSB overview and progress report (Ian Murdock)
I will present the standard LSB slide deck with a particular focus on progress since the last face to face meeting, to ensure we're all starting the meeting on the same page. I will also present the current draft of the LSB 3.2 roadmap and timeline. Finally, I will talk about organizational issues, the modular structure of the LSB, etc. as they relate to LSB 3.2 development.
|10:00am - 10:45am||Feedback: What do key platform stakeholders (distribution vendors, ISVs, OSVs, upstream developers) want from LSB 3.2 and beyond? How does/should the LSB add value?|
|10:45am - 11:00am||Break|
|11:00am - 12:00pm|| Overview of the LSB infrastructure project (Vladimir Rubanov and Alexey Khoroshilov)
|12:00pm - 1:00pm||Lunch|
|1:00pm - 1:30pm|| LSB Distribution Testkit (Jiri Dluhos, Alexey Khoroshilov, Ian Murdock)
Overview of the plans for the LSB Distribution Testkit (companion to LSB Distribution certification), demos of lsb-autotest and the LSB Test Execution Framework (TEF), and discussion of planned integration with the FSG certification system.
|1:30pm - 2:00pm|| LSB Application Testkit (Jeff Licquia)
Overview of the plans for the LSB Application Testkit (companion to LSB Application certification), demo of the new appchk, and discussion of planned integration with the LSB database and Developer Network.
|2:00pm - 2:30pm|| LSB SDK and packaging tools
The current LSB SDK makes it easy to create an LSB compliant binary, but doesn't yet make it easy enough to create a distributable, easy to install LSB compliant application (I'm avoiding the term "package" here, intentionally). Longer term plans will be discussed in Wednesday's Packaging Summit. In this session, we'll discuss shorter term plans for making it easier to create distributable LSB applications that integrate well, such as including RPM helpers, alien, APT/yum repo generators, etc. in the LSB SDK.
|2:30pm - 3:00pm||Break|
|3:00pm - 4:00pm|| Perl, Python, and other interpreted languages
An increasing number of "Linux" applications are being written in or augmented with Perl, Python, and other interpreted languages. As a result, we will be adding Perl and Python to LSB 3.2, so that application developers can write LSB compliant applications in those languages in addition to C and C++. However, the addition of interpreted languages presents the LSB with some new challenges, such as whether or not add-ons (e.g., gtk bindings) should be standardized and how to handle binary extensions. See also: LsbInterpretedLanguage, LsbPerl, LsbPython. Martin v. Löwis of Python will be joining us for this discussion and helping with Python standardization in LSB 3.2.
Incorporating Python into LSB: Identification of Issues (Martin v. Löwis)
|4:00pm - 4:45pm|| LSB Developer Network
In October, the FSG launched the LSB Developer Network, a community resource for developers building portable Linux applications via the LSB. In this session, we will discuss current status and future plans for the Developer Network, including collaboration possibilities with other developer communities.
|4:45pm - 5:00pm||Day one wrapup|
LSB face-to-face, day two (December 5)
Day two will center around finalizing the roadmap and timeline for LSB 3.2 (June 2007). 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.). We will also discuss LSB futures (LSB 4.0 and beyond).
|9:00am - 9:15am||Review of day one, overview of day two (Ian Murdock)|
|9:15am - 9:30am|| LSB 3.2 printing roadmap and timeline (Ian Murdock)
I will present the final LSB 3.2 printing roadmap and timeline prepared at the FSG Printing Summit in October. This presentation is both to inform attendees of our printing related activities for LSB 3.2 as well as to provide a guide of what I want to produce for the rest of LSB 3.2.
|9:30am - 10:30am|| Core and C++ (Mats Wichmann)
In general, not much is changing here. However, we need to look at the following issues:
|10:30am - 10:45am||Break|
|10:45am - 12:00pm|| Finalizing LSB 3.1 Update 1 (Mats Wichmann)
We will be releasing the first update to LSB 3.1 in early 2007. The current working timeline is to release the beta on December 15 and the final version on January 15. In this session, we will finalize the timeline and go through the to-do list to determine what will make it into the update and what won't.
|12:00pm - 1:00pm||Lunch|
|1:00pm - 1:30pm||Accessibility (Olaf Schmidt)|
|1:30pm - 2:00pm|| Multimedia (Donya Shirzad)
LSB 3.2 will focus on device level standards (e.g., ALSA, libao). LSB 4.0 will focus on the higher level multimedia frameworks (e.g., GStreamer, Helix).
|2:00pm - 2:30pm|| OpenI18n
OpenI18n is being merged into the LSB beginning with LSB 3.2.
|2:30pm - 2:45pm||Break|
|2:45pm - 4:15pm|| LSB Futures (or: LSB 4.0 and beyond)
|4:15pm - 4:45pm|| Desktop
LSB 3.2 Desktop Updates (Tracy Camp (by phone))
|4:45pm - 5:00pm||Day two wrapup|
Packaging Summit (December 6)
The main packaging systems under Linux include three main components: a format for bundling software to be delivered onto a system including mechanisms for indicating dependencies on other packages; a database for tracking installed software; and utility programs for creating, installing, and manipulating software packages. Many higher-level systems (e.g. apt, yum, RHN, urpmi, Red Carpet) exist which provide an easier to use user interface, but still depend on the package format and database. The LSB currently contains a specification for the package format only, leaving the other parts as implementation details.
For a variety of reasons, third-party developers may be unwilling or unable to use the native package systems, and may use some other mechanism such an installation script or a cross-platform installation framework like InstallAnywhere. The reasons are varied, but typically have to do with controlling the user experience and providing better cross-platform support, since Linux is almost always just one platform that's supported among others. It is quite difficult for external packagers to effectively tie in to the automatic dependency generation which is an important part of the distribution-provided packaging, and doing so often makes the vendor package less portable than is desired. The LSB does attempt to simplify this by providing a single dependency ("lsb") for packages which covers all of what the LSB covers.
The methods used by third-party developers effectively just dump files in the file system and integrate poorly with the underlying package systems, which is a problem for system administration, IT support, compliance audits, and many other reasons. At the LSB face to face in June (and elsewhere) it has been proposed to construct an API to the native package systems (dpkg, rpm) so that higher level installer frameworks can register with them. That way, third parties can completely control the installation experience, yet the end result is properly integrated with the distros' software management tools. More discussion is needed here, making it squarely a 4.0 issue.
|9:00am - 9:30am||Overview, goals, and motivations (Ian Murdock)|
|9:30am - 10:45am|| ISV issues: What do ISVs want to see in a Linux software management solution?
|10:45am - 11:00am||Break|
|11:00am - 12:00pm|| Distribution issues: How do distros see the software management problem?
|12:00pm - 1:00pm||Lunch|
|1:00pm - 1:30pm||APT (Michael Vogt)|
|1:30pm - 2:00pm|| Yum plans post-API freeze (Seth Vidal)
Some of the loose plans we have for the 3.2.X cycle following on the API freeze for 3.0. What these plans mean for fedora and other distros using yum and what things we hope to do.
|2:00pm - 2:30pm||alien (Joey Hess)|
|2:30pm - 3:00pm||Break|
|3:00pm - 3:30pm||Packaging for people who aren't distros: autopackage and other problems (Mike Hearn (by phone))|
|3:30pm - 4:00pm|| The philosophy behind klik: 1 application = 1 file (Simon Peter)
klik is an easy way to download and use software. The idea behind klik is that software should just run, without the need for installation. To achieve this, klik uses compressed image files, not unlike Mac DMG files, that contain the entire application and all its dependencies that are not part of the (LSB) base system. This allows for "portable applications" that can be run from all media, e.g., USB thumbdrives. Presentation
|4:00pm - 4:45pm||Open discussion: What can the LSB do to improve software installation and management on the Linux platform? (Ian Murdock)|
|4:45pm - 5:00pm||Packaging Summit wrapup|
- Stew Benedict (Mandriva) (via phone)
- Hans Friedrich Blenkle (Xandros) (Tuesday and Wednesday only)
- Darren Davis (Novell)
- Joachim Deguara (AMD)
- Jiri Dluhos (Novell/SUSE)
- Falko Flessner (SAP)
- Andreas Hahn (SAP)
- Joey Hess (Debian/alien)
- Till Kamppeter (FSG)
- Alexey Khoroshilov (ISPRAS/linuxtesting.org)
- Dan Kohn (FSG)
- Matthias Klose (Canonical/Ubuntu) (Monday and Tuesday only)
- Thorsten Kukuk (Novell/SUSE)
- Pascal Lauria (Xandros) (Wednesday only)
- Michael Leibowitz (Intel) (Wednesday only)
- Jeff Licquia (FSG)
- Martin v. Löwis (Python)
- Ian Murdock (FSG)
- Paul Nasrat (Red Hat, Software Installation (Anaconda, RPM, yum))
- Simon Peter (klik)
- Vladimir Rubanov (ISPRAS/linuxtesting.org)
- Steve Schafer (FSG)
- Olaf Schmidt (KDE/FSG Accessibility workgroup) (Tuesday and Wednesday only)
- Michael Schroeder (Novell/SUSE) (Wednesday only)
- Robert Schweikert (ABAQUS)
- Donya Shirzad (RealNetworks)
- Seth Vidal (Fedora, yum lead developer and maintainer)
- Michael Vogt (Canonical/Ubuntu, APT/Synaptic maintainer)
- Mats Wichmann (Intel)
Regular flights to Berlin usually arrive at the Berlin-Tegel (TXL) or the Berlin-Schoenefeld (SXF) airport. Both are well connected to the inner city via shuttle trains and buses. The SAP building itself is located at Rosenthaler Str. 30, 10178 Berlin. Global coordinates are N: 52° 31.559', E: 13° 24.175'.
The next underground metro station is "U Weinmeisterstrasse", which is direct in front of the SAP building. The next urban rail system station is "S Hackescher Markt". More informations about public transport services are available at bvg.de (english version).
SAP has a Partnership with hotel.de. Choose the location "Berlin - Rosenthaler Str. 30" to find hotels nearby the SAP office.