LSB F2F Spring 2010

The Linux Foundation Collaboration Summit is planned for April 14-16, 2009, in San Francisco. Details on the summit are available.

Because of limited opportunities for travel, the LSB workgroup is planning its Face-to-Face meeting to co-locate with the LF Collab Summit, starting Monday, April 12, and going into Tuesday, April 13. These two days will be focused more on internal LSB business and activities. We will also have a session on the LSB during the Summit itself. This is not a private meeting: everyone who can carve off the time is welcome to participate and help influence the future direction of the LSB.

We intend to make the F2F more informal, with topics and schedules decided in more of an "unconference" format. Topics are listed below; additional topics may be added during the F2F.

The LSB session during the Summit itself will be focused on interaction with the community and with vendors. A schedule for the Summit session follows.

experimental Facebook/Twitter "social" presence seems okay, but should not become primary. Announce more widely? (at least links on homepage to these)

LSB SI: switched to rPath-based si, but never released formally, what to do (that is, no 4.0 si)?

nobody here knows rPath well without Antonio; old LFS-based build suffered rot in that nALFS tool and associated profiles not used/maintained, so effectively no upstream

SI use cases: clean LSB-only environment for testing; proof of concept for conforming distro; early access to new LSB version before distros come out; selected toolchain w/o lsbcc

Of those, the LSB-only is the most valuable, but could be implemented in other ways. dyncheck actually meets need, but stale code / no time to work on. A simple tool could be enough:

App checker would instruct to run app under "lsb_test" only if it detected use of untestable interface (like dlopen), wrapper uses LD_PRELOAD to trap on such usage

Pain to use lsbsi for app developer: one more thing to set up, with weird conditions, needs root, etc. - barrier

Conclusion for now is to give no effort to lsbsi but don't kill outright; see where cert docs need revising to not require it; explore writing the small tool; confirm that the appchk warning is still appropriate

Decision: select "exemplar apps" and make sure those have any patches documented, bugs filed on needs, etc.

What issues are outstanding regarding the certification of library-only components?

amend cert document with procedure for library cert

developer run customary QA procedure on two LSB-certified distros, test program does not need to be conforming itself

libraries pass appchk

some questions on the installation side, maybe don't need to say anything here, and depend on ISVs to behave sanely and do the right stuff from a QA viewpoint, not LSB's

should document intention of lib cert: certified lib can be included in an app without worrying about further conformance issues

Tuesday

Moblin and MeeGo: what do we have to do to continue supporting that project?

Desire to keep a line drawn between LSB and other projects such as MeeGo: keep clear on LSB's focus without letting it bleed into others, yet depend on participants as individuals to make sure areas of commonality are fully exploited

Sub-topic: possible ARM profile for the LSB - LSB can advise; whether such should go into LSB remains an unanswered question:

alsa tests: markup done, but tests for all is 1-2 man-years total, so can only do some key interfaces: identify and proceed: top 15 interfaces

build/release infrastructure completion: we think 4-6 weeks work

based on this set of concepts, we'd end up with a feature freeze Oct 1 - need to write this up and get closure with workgroup, poss target release Dec 1

State of the LSB (moved from Mon, waiting for more people - which we didn't get)

Are we spending our time wisely?

Feeling we're hamstrung by non-participation by multiple parties who should be stakeholders, may not be able to fix

There are several aspects to LSB - spec, distro testing, application development, docs/tutorials ("LDN") and other website/info delivery stuff, plus less visible things like build/release infrastructure, support of old releases, certifications, etc.; should the relative priorities of those be adjusted based on the current impact areas of LSB?

for now we think mostly okay, subject to bugfixing most serious web breaks and the value discussion

Day five (Friday, April 16)

We will have a joint session with the OpenPrinting workgroup in the morning sessions. The afternoon sessions will be a wrap-up of the discussions from the beginning of the week, and will be scheduled in an "unconference" format, with the agenda and schedule set as the first item of the agenda in the afternoon.

News:

Epson has released the first LSB-conforming print driver package

These spilled over from Mon/Tue:

Modularization of the LSB components: the "big gulp" approach is claimed to be problematic, particularly when an app ends up pulling in lots of stuff that depends on lots of other stuff. Is there a sane way we can address?

when instantiating an app in a conforming environment: "I need X" and the only choice for X is "all of LSB". How about if we leave distros needing to certify to "LSB" but apps can describe their dependency in a more granular form

the ISV boundary: if there are too many choices, it gets too confusing - with above, we can fix this at the App Checker level (tells you what components you used)

OR: is this really a case of, LSB is a model for how to build other conformance projects, effectively built as derivatives of the app checker

Resolved: LSB certification is not changing (now)

Question of whether to expose modules, submodules, or both: general feeling is "both"

Upstream relations. Are we doing better? Why or why not? How can it be improved?

Sub-topic: getting upstreams to adopt conformance testing.

Sub-topic: getting upstreams to write LSB-style conformance testing.

Library uplifts? Start planning 4.2, maybe a shorter cycle?

OpenGL, Cairo, Qt, Gtk ???

Dropping Qt3 as required - when?

Drop in 4.2, leave in 4.1 - except that if 4.1 ends up delayed signficantly we could look again

Deprecation policy needs to be based on time rather than #releases, since release cadence is indeterminate - minimum 3 year

Conference call information

During our sessions, we will maintain a conference call line for those who wish to dial in and participate. The conference call line will be the same as that used for the weekly conference calls: