summary of the LSB meeting

[Aaron J. Seigo]

hello ...

as you likely are aware of, i went to an LSB face-to-face meeting last week. 
here's the summary of what went down according to my notes:

the consistent message and question was: "how do we make the LSB relevant to 
software developers?" that's the goal foremost in the mind of those involved, 
now being led by Ian Murdock.

there were people from red hat, novell, multimedia projects (helix and mas), 
kde, ibm, intel, canonical, x.org, linuxtesting.org and of course the FSG. (i 
also probably missed some org =). it was still a relatively small meeting: we 
all fit at one table. and that was where we sat for ~16 hours over 2 days 
working through things.

LSB 3.1 is out and we're looking forward to what 3.2 and 4.0 should be. it was 
stated that the LSB is not meant to be a place to push technologies into 
standardization, but to formalize the standards as they emerge. so, for 
instance, it isn't for the LSB to require the Linux kernel to have a stable 
ABI for drivers. but if that happens, the LSB would be there to formalize the 
description, house test suites, get it into the ISO track, etc.

coordinating all of this with upstream developers (that's us) as well as 
distributions is seen as critical. the LSB aims to become both an umbrella 
that sits over organizations such freedesktop.org to formalize what they 
arrive at as well as an "anticipating" standard. a good example of the latter 
is that while not everyone may be shipping qt4 packages -today- it's there as 
an optional module; this signals the OSVs (operating system vendors) that 
there is a direction there we need to be following. qt4 is a given, the LSB 
is responding to that. similar things will and are happening to other such 
technologies (though qt4 is actually the first actual example =)

as for distros involved right now that list includes Asianux, Beijin 
Co-Create, Debian Etch, Linspire, Mandriva, RH, Sun Way, SUSE, Ubuntu, 
Turbolinux, Xandros. Sun is also apparently interested, so this extends 
beyond just Linux for many of those involved.

the question was asked: What makes a good platform? the answers provided 
included:

	Broad enough scope (meeting needs)
		Direct ISV feedback (LSB does not currently specify enough)
		Proactive in "filling in gaps"
	Uniform, stable, consistent, backwards-compat API/ABI (investment protection)
	Predictability (what's the road map?)
	Developer friendly ("MSDN", developer tools, learning curve)

for 3.2 the goals include:
=====
GCC 4.1 / libstdc++ v7
glibc 2.4
language runtimes (perl, python, java..?)
x-desktop interop (fd.o)
i18n (font management & input methods)
accessibility
multimedia
packaging
printing
and with a big question mark: wine
what else...? still formulating

Must improve testsuites
Infrastructure
	How is the roadmap defined?
	Who does the work?
	What can be automated?
Franchised dev/cert program
Binary compat over time (LSB3->LSB4, e.g.)
Interface with distros? ISVs? Upstream? extra-FSG?
=====

there was a lot of talk about C++ and actually getting the ABIs in order. 
people are serious about getting this done properly with big name vendors 
saying they need to put resources to it and community coordinators such as 
John Hall noting they will look into getting a face-to-face "hot house" 
together. i let them know we have a few c++ experts around that can help 
identify issues real world projects run into if needed. this was welcomed.

on the topic of multimedia, it was agreed that it's not the right time to try 
and standardize something like gstreamer. it is the right time to work on 
getting the layer that alsa, libao, etc reside on so that people writing 
multimedia frameworks and apps have a common interface to target. we'll move 
our way up the stack from there and the LSB is creating a multimedia working 
group to facilitate that.

IBM presented on their "chiphopper" program which is a long-term initiative to 
help ISVs port/write applications to/for linux. they provide hardware and OS 
images to test with, LSB compliance packs, etc.. they have 150 ISVs active in 
the program right now and over 300 apps online. almost all of these ISVs are 
multi-language (programming language, not natural language ;) with Java being 
the most common, C/C++ being the next most common, a smattering of 
Python/Perl/Ruby and that's about it. so it appears if we want ISVs, we need 
to get in with the LSB (that gets us in with things like chiphopper as an 
incidental) and support C/C++ and Java. straightforward.

the four least controversial, most accepted freedesktop.org specs (e.g. the 
desktop file spec) and the attendant portland project implementations were 
examined as well. these will be making their way into the LSB in one form or 
another. dbus came up in this conversation as well as it needs to get to a 
state where it can be formalized for inclusion.

fonts were also looked at. a common, shared font repository was discussed. it 
seemed to gain traction. more work needs to be done here, but it looks like 
we can pull the various interests (mostly distros) together with enough time 
and effort. apparently it's not really like red hat -wants- to be in the font 
foundry business though they are out of necessity =)

btw, the red hat lsb fellow is a huge kde fan ... =)

printing standardization was also discussed. this is happening through 
linuxprinting.org, of course. there was pushback on standardizing CUPS right 
now due to new developments coming down the pipe that might make it more 
sensible to standardize a different set of APIs which CUPS would then be one 
implementation/provider of. there were too many acronyms for me to keep up 
with here, but it seems a lot of (good) development is happening here and at 
a good pace to boot.

there was discussion of a common packaging API 
for "installanywhere"/"installshield" type apps to use. at first there was 
pushback from distros but by the end after open and frank discussion and 
Ian's graceful handling of things there seemed to be consensus that this was 
a possibility indeed. still a long way sto go on it, but something ISVs are 
pushing for and something that, with enough flexibility, the OSVs agree they 
can probably provide. this is not to be a replacement for .deb or .rpm or 
apt-get/yum/etc but a way for OSVs to provide simple hooks to register files 
with the package management system in an OS-neutral way. think "phonon for 
application installation". OSVs will still use the full power of the native 
packaging systems of course.

accessibility was also discussed and is accepted as a must have. the keyboard 
spec which is well defined and implemented fully in both kde and gnome gets 
the nod with at-spi on the horizon. this likely depends on dbus getting into 
the lsb due to qt/kde using dbus for this.

i18n was discussed a bit as well, though nothing earth shattering, or even 
really interesting, there.

linuxtesting.org showed their automated testing suite which includes code 
coverage annotation tools, spec->natural language tools and the real-world 
lsb test suites they are running that turning up real bugs in the specs. i 
passed on their info to our own q/a meister mr. de Groot in hopes that this 
can help our efforts as well and they've been talking since by email.

so this was an auspicious beginning. i've tried to keep this email succinct, 
but as you can see a lot was covered. i'm happy that we are involved right 
from the start of the desktop initiative and have a very prominent role to 
play. it looks like i'll be joining the advisory committee as well which will 
help ensure we maintain our role. everyone sees this as a desirable thing; in 
fact, it was offered without us having to ask =)

there'll be weekly phone conferences for me to attend, and if anything comes 
of those i'll keep you posted.

apologies for the stupidly long email and remember kids: standards are fun, 
stay in school and play safe! =)

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060607/ed17e745/attachment.sig>