LSB F2F Spring 2010

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

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

The Linux Foundation, parent organization of the Linux Standard Base, held its annual Collaboration Summit April 14-16, 2009 in San Francisco. Given the budgetary restrictions many participating organizations are facing this year, the LSB workgroup held a Face-to-Face meeting co-located with this event, including the two days prior, April 12-13. The first two days were focused more on internal LSB affairs: planning activities for the workgroup and so on. An LSB session was held during the main Summit period to focus more on external issues: presentations on applications of the LSB, testing technologies, etc. On the final day of the summit, more workgroup planning work was done. As has been the case at recent meetings, the F2F portions was relatively informal, following the "unconference" format, in other words, while there were a set of requested topics ahead of time, the agenda was determined and evolved interactively during the meeting. A brief bullet-point summary follows.

Day 1 (Monday)

  • 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

Day 2 (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:
      • 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 3 (Wednesday)

This day was left for the main LF Summit activities, there were no LSB-specific sessions.

Day 4 (Thursday)

This was the planned day of presentations, as follows:

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 5 (Friday)

AM: Joint meeting with OpenPrinting. On the OpenPrinting meeting page is a link to the items requested for LSB development; essentially it involves completing the CUPS interfaces that were left out earlier, as well as support for dbus and udev as the former is needed for interactive dialogs from printing events and the latter for setup issues when a printer is attached. The printing group is driving towards many interesting developments, which will include better support for printing without so much setup - especially for mobile device support but also many other reasons - but much of this will take some time to evolve.


  • Epson has released the first LSB-conforming print driver package

PM: Resume LSB F2F

These were the remaining topics after the Mon/Tue sessions:

  • 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"
  • 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
  • Library uplifts? Start planning 4.2, maybe a shorter cycle?
    • OpenGL, Cairo, Qt, Gtk ???
      • Gtk 2.10: we need something to exercise the key new features (esp. printing dialog) - if so, we could do if it doesn't slip the schedule (note: this has OpenPrinting as a "customer")
      • Do Cairo for 4.1, since have the patch already
      • Qt is waiting for Nokia proposal, when we hear we can make a decision
      • Do the others for 4.2
  • LSB "Community Edition" ?
    • Vigorous discussion of how we could apply some changes earlier
    • Objections that it's too early to be doing these things when we haven't proven we can do regular releases reliably
    • Some way to do a staging tree, even though that may be unsatisfying to the contributor
  • 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.