|| ||"Aaron J. Seigo" <aseigo-AT-kde.org>|
|| ||summary of the LSB meeting|
|| ||Wed, 7 Jun 2006 09:51:10 -0600|
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
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
language runtimes (perl, python, java..?)
x-desktop interop (fd.o)
i18n (font management & input methods)
and with a big question mark: wine
what else...? still formulating
Must improve testsuites
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)
to post comments)