My monthly 'oh yeah, the platform' mail

[Mike Hearn]

> This LSB process *should* be more conservative even than
> freedesktop.org. Though they have been moving somewhat too slow on the
> desktop front, that's largely due to lack of volunteers and assistance
> from what I've seen. Because the LSB goes further than just releasing
> the software, and creates validation tests for ABIs (to be sure they
> didn't change) and for ISV apps (to be sure they don't have extraneous
> dependencies) it simply takes some work. But this stuff is useful.

I have to admit, I'm not convinced about the value of LSB-level
validation tests especially given the momentum problems they seem to
bring. Any upstream project which is committed to stability:

a) Should be reviewing patches to make sure they don't break apps,
   which obviously includes "don't rename or remove symbols"
b) Ideally has these interface tests already written

I hesitate to call them ABI tests because really what you want is a
stable programmatic, binary and semantic interface. Focussing purely
on the ABI is missing a ton of things that can break programs (eg,
most of the old Loki games are now broken due to various changes, not
all ABI related).

> Another way to look at LSB: they are not releasing software. They're
> releasing a contract-enforcement layer between the ISV and the software.
> This is a fundamentally different thing from a
> freedesktop/X.org/GNOME/KDE release.

To be honest I don't think the LSB can do much if a particular piece
of software does not have upstream maintainers committed to
stability. So I'd rather have an LSB that specified less but contained
more, ie delegated more to upstream maintainers who "got" the
stability religion.

As it is even the X libs which are in the LSB 2 graphics spec are too
limited. For instance the Java JVM broke because libXp was moved into
x11-deprecated-libs, and libXp isn't a part of the LSB.

> A danger for the open source desktop is that ISVs look at the huge
> collection of libraries available in your average distribution, use a
> few of the ones that "everyone" knows are crap, and are turned off when
> they get shafted by the decision. There's really no good guidance on
> which of the zillion things in /usr/lib are considered OK. And for all
> of them you can find some nitwit on the Internet who will say it's the
> best thing ever.
> 
> This is why having a line where we say "these are the libs to use" is
> useful. But that line has to be oriented toward *keeping ISVs from
> getting shafted* not toward *getting ISVs to use half-baked gee-whiz
> stuff*

Absolutely, agree 100% with this. Problem is right now the only
document that comes close is the LSB which doesn't cover anywhere near
the amount of functionality modern apps require. So ISVs (like Sun)
still depend on libs which look safe like libXp that then disappear,
because they have no choice.

By implication that means any such list of stable libraries has to be
pretty big.

Let's say that we ran with Havocs suggestion and put fontconfig in any
such freedesktop.org platform. What does this really mean? Obviously
it means that you can depend on it being present if you depend on FDOP
1.0, as toolkits/desktops and maybe apps will, but does it mean:

- fontconfig will maintain a stable library interface
- fontconfig command line utilities will remain stable (ie, not remove
  or change options)
- fontconfig XML config file will remain stable

etc. What are Keiths plans for this code long term? What sort of
guarantees does being in the platform imply? Same questions apply to
any specs put into the platform as well of course.

I've seen quite a lot of discussion about how to decide what goes in
and what stays out. Maybe I missed it, but where is the list of what
being in means for a particular project?

thanks -mike