LSB F2F Spring 2010

From The Linux Foundation
Revision as of 21:08, 16 April 2010 by Mats (Talk | contribs)

Jump to: navigation, search

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.

Days one and two (Monday, April 12, and Tuesday, April 13)

9:00am - 12:00pm Morning session.
12:00pm - 1:00pm Lunch
1:00pm - 5:00pm Afternoon session.

Here's a bullet-level summary of the discussion, as the topics flowed out:


  • How do we do releases
    • hung up on "it's not done until all the distros certify"
      • has impacted dev't effort, may be partly our own fault (that is, is tech WG "channeling" extra issues they think might be brought up)?
    • what does WG feel it should do? overall objective may change that, but should have a plan
    • Proposal:
      • Pick date and freeze for release
      • Give four-six weeks for distros to certify to be in release announcement (we'll have been working with them earlier)
      • Ship it
  • "lsb" package seems to be a hangup for some
    • can we reach the goal of "a way to insure the full environment is present" without effectively requiring the package (spec doesn't specifically require it now, just the "Provide")
    • could we provide? not really, chain of responsibility is wrong
    • relates to modularization question (more on this Tuesday)
      • modularization means more dependency complexity on surface - what to depend on?
      • is it simpler for distros to manage? at least can manage dependencies on a smaller scale
      • a data-driven tool on LSB end may be able to identify app dependencies better, including "new app on old distro" problem
  • Version-independent components, one year later
    • we're happy with the concept, but not with the bottleneck: too dependent on the release manager (Jeff) to push entire process through; missed several intended time-based releases
    • tools still being improved
    • this is getting considerably better, but want to get to where RM is gate (does sign-and-release), rather than bottleneck (block everything)
    • also autobuild production-level stuff regularly, not just devel
    • time-based is okay, but should be able to do demand-based if needed (key bugfix shouldn't take months to deploy)
    • need to get better on testing, some former tests not run now (appchk/pkgchk on appbat), and some regression tests would be good (don't let old bugs come back)
      • important to improve handling of ispras releases, which we rebuild, run different tests on, and release - too slowly at the moment
    • "Easy Button" -- turn the crank to build/prepare release
  • Website and other communication methods
    • we have a mess of at least four "websites" - entry under LF workgroups, old LSB wiki, LDN,
    • navigation too hard, stale data, etc.
    • LSB "homepage" is a bunch of text before you get to real links
      • how about the classic first-page navpage style of one intro paragraph, then 2-4 buttons that quickly redirect you to functional area
    • Focus: homepage (wireframe), navigation plan, downloads (filtering by version/architecture/distribution method aka tarball vs. rpms vs noninstall bundle)
    • LDN as developer site vs. news aggregator - at least aggregate from better sources (linuxjournal?), some of current news is not interesting developer content
    • Identify overlap between LDN and
    • LDN classification/presentation
    • Drupal OpenSearch plugin for better search, integrate with Navigator, so search on interface returns something
    • 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
  • Appbat
    • Builds require patches, are issues tracked? We try to pick apps that build w/o patches, but it's unavoidable sometimes
    • Also use apps as ways to exercise LSB features, e.g. at least one app touches each lib - there might be many patches needed for some of those
    • Claims that apps just not useful as porting example
    • Decision: detach lsb-python from appbat at 4.1, move to test tools (solves specific problem caused by dual nature of lsb-python)
    • 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


  • 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:
      • are there distros interested in certifying?
      • are there apps which would be interested
  • Summer of Code 2010: act on proposal(s)
    • discussed topics put up from ispras and student proposals. Project prio ranked thus: Test Generation; LSB Test Analysis; Dependency Translator; Upstream Tracker; Driver Quality
  • Java status: 2009 Summer of Code project, status of the standard in LSB.
    • Pushing GSoC patches to openjdk: not upstream now, apparently weren't of sufficient quality
      • would like to have clearer view from upstream what would be needed
      • even setting up to build is tough, no owner for patches now
    • patches to LSB tracked in bug 2674
    • status of standard remains uncertain - has to remain trial use for now (esp. in light of ownership change: need to reopen dialogue)
  • LSB tools "case study": Scott Baeder's report
    • performance was poor with the app checker version used (old, but where our website pointed)
    • see some interesting usage of libraries by libraries local to the project (good info for developer organization)
    • libgmp (plus tls considerations), libelf have high importance for this app
  • LSB 4.1 status. Are we ready to freeze and prepare for release? If not, what is needed?
    • Goals: new symbols, infrastructure, alsa tests
    • symbols take page writing; other tasks relatively easy (db adds generate out to checkers, sdk)
    • 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
      • WG requests this prio: infrastructure, web work, 4.0 update, continued distro testing, 4.1 work (items listed above)
    • Should we be looking at expanding the footprint (more libs for developers) or is more of a maintenance mode more appropriate?
    • 4.0: we didn't get the release done right (no announcement); how do we fix to launch 4.1 correctly
    • Problem showing success/values to stakeholders, including both internal (LF, board, members) and external (ISVs, distros, projects) esp. vs what has been promised
    • PR problem (external) is because no "steering committee" (perhaps not right term): need to reactivate - someone who can drive this level
    • How can we drive into new value areas, "LSB lite" model for example?
  • Quality improvement: we're always trying to improve tools, build processes, ease of contribution, collaboration with other groups. Are we making progress? What should go on the plan for the next year?
    • ease of contribution too hard: e.g. we could use help testing 4.0 updates, but it's hard for someone other than core team to spend a few minutes testing
    • Decision: project plan/status review will happen at beginning of alternating weekly confcalls, we haven't been staying on top of progress clearly enough
    • Sub-topic: what have we learned from the T2C ALSA test project? How easy is it to collaborate with that framework? Can we make it easier?
    • No strategic vision today
  • Too many open bugs
    • In the case of devel-level distros, can we run tests less often? Conflicts with getting the feedback into the loop quickly
    • SI bugs become "wontfix"
  • LSB WG plans a meeting for final 4.1 wrapup plus delivery of PR plan (LinuxCon Boston)

Day three (Wednesday, April 14)

This day will be spent taking part in the keynotes and panel discussions of the LF Collaboration Summit. See the main agenda for this day's schedule.

Day four (Thursday, April 15)

9:00am - 9:15am Welcome, introductions, overview. (Jeff Licquia, Linux Foundation)
9:15am - 10:15am State of the LSB. (Jeff Licquia) A summary of where we are and where we're going. Results from Monday and Tuesday's sessions will also be discussed.
10:15am - 10:45am Break
10:45am - 12:00pm Using the LSB in Application Development. (Robert Schweikert, Novell)
12:00pm - 1:00pm Lunch
1:00pm - 2:00pm Beyond unit tests: an introduction to conformance testing. (Jeff Licquia)
2:00pm - 3:00pm Why should you worry about conformance testing? (Alan Clark, Novell)
3:00pm - 3:30pm Break
3:30pm - 4:30pm Demonstration of writing conformance tests with the T2C framework. (Alexey Khoroshilov and Vladimir Rubanov, ISPRAS)
4:30pm - 5:00pm What obstacles exist to widespread adoption of conformance tests? (Jeff Licquia)

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.


  • 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
    • Robert: need to decide on certification - will there be one, or profiles; can't build directions before that
  • 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?

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:

Conference Dial-in Number: (605) 715-4920
Participant Access Code: 512468

In the event of technical difficulties, please check with IRC (, #lsb) or reload this page for updates or alternate arrangements.