[lsb-discuss] LSB conference call minutes (Tuesday, July 18, 11am ET)

Ian Murdock imurdock at imurdock.com
Tue Jul 25 06:51:18 PDT 2006


Attendees: Stew Benedict, Todd Fujinaka, Marvin Heffler,
Andrew Josey, Till Kamppeter, Jeff Licquia, Ian Murdock,
Robert Schweikert, Nick Stoughton, Kay Tate

* Printing and LSB 3.2. Continuing debate on whether CUPS should be
added to LSB 3.2. It's best practice in the Linux world but not outside
(e.g., Solaris). So, adding CUPS would be, for all intents and purposes,
adding a "Linux-specific" feature to LSB, which we've been reluctant to
do previously. So, this is an instance of a larger issue: Should LSB be
Linux-specific, or should it continue to be a goal to be Linux-
independent so other UNIXes can be LSB-compliant? Ian is talking
with Sun about LSB compliance for Solaris, to see if our Linux
independence is just theoretical or if there's actual meat to
it. The decision will be made on the August 1 conference call.

Irrespective of the CUPS question, it was noted that the main driver of
getting printing into LSB 3.2 are desktop ISVs, and that the desktop
toolkits (Gtk/Gnome, Qt/KDE) might be more suitable for desktop
printing. Gtk 2.10 is out because it's not in at least one of the major
distro targets for LSB 3.x (RHEL 5, SLES 10, etc.--can't
remember which). However, we can possibly include the Qt/KDE interface.

* Discussion of backward compatibility. Backward compatibility across
major versions of the LSB is a new goal beginning with LSB 3. So, if
an ISV targets LSB 3.1, its application will run on any LSB runtime
that's compliant with version >= 3.1, and that includes 4.x, 5.x, etc.
(This was previously not guaranteed.)
Of course, it needs to be possible to deprecate interfaces that are no
longer used after some reasonable period of time--otherwise, the distros
keep accumulating interfaces that are no longer being used just to
preserve the backward compatibility guarantee. Nick pointed out that the
current policy is that an interface needed to be marked deprecated for a
full major version before it could be removed. Robert suggested that,
from the ISV's point of view, the time period needed to be longer than
that--a full major version is only about two years. Three major versions
was suggested as a better target, which equates to about six years. Ian
pointed out that, given the longer timeframe, we need to be
even more careful about what gets added to the LSB, which is part of
what's motivating our deliberateness on the CUPS issue (once it's
there, it'll be hard to remove, even if we decide to change course).

* Long and useful discussion about making it easier to run the runtime
tests. In summary, we want a single framework with a single script that
produces a single output file. Today, we have a single "testkit"
tarball, which essentially bundles all the runtime test packages, but
it's still necessary to run each of the test suites individually, and
each test suite creates a separate journal file, often in a different
location. Ideally, the testkit is a framework that is downloaded, and
the appropriate tests are automatically fetched as needed. A single
"run-tests" script is run (potentially just a layer above individually
developed and managed test packages such as we have today), and a single
tarball of the journals is created. We'd also like to integrate the
runtime test framework with the new certification system. For example,
the questionnaire at the beginning of the test run (e.g., whether the
runtime environment supports csh) is part of the product registration
process, and the test results are automatically uploaded into the
certification system, with a variety of web-based analysis tools
available in the certification workflow. Jiri Dluhos' lsb-autotest
already does quite a bit of the above, and we'll be exploring
whether we could use that as the new official LSB runtime testkit.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige




More information about the lsb-discuss mailing list