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 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. All are invited to arrive early who wish to participate and possibly 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
| 1:00pm - 5:00pm
|| Afternoon session.
As noted, days 1/2 didn't have a specific preplanned agenda, starting from a list of pre-requested topics we ended up with:
- How do we do releases
- hung up on "it's not done until all the distros certify", has impacted dev't effort
- aka, has business side hamstrung tech side too much (that is, is tech WG "channeling" extra issues they think would 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
- Four-six weeks for distros to certify to be in release announcement
- Ship it
- "lsb" package seems to be a hangup
- can we reach the goal of "a way to insure the full environment is present" without effectively requiring the package
- 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?
- may be 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: time for the release manager (Jeff) to push things through; missed several intended time-based releases
- tools still being improved
- this is getting considerably better, but want to get to RM is gate (do sign-and-release), rather than bottleneck (block everything)
- also build 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" - under LF workgroups, old LSB wiki, LDN, ispras.linuxfoundation.org
- 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 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 is not interesting developer content
- Indentify overlap between LDN / linux.com
- 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 "new" homepage to follow)
- LSB SI: switched to rPath-based si, but never released formally, what to do (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. but 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
- 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, like all libs - 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
- 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)
- 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?
- Upstream relations. Are we doing better? Why or why not? How can it be improved?
- Sub-topic: getting upstreams to adopt conformance testing.
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
| 10:45am - 12:00pm
|| Using the LSB in Application Development. (Robert Schweikert, Novell)
| 12:00pm - 1:00pm
| 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
| 3:30pm - 4:30pm
|| Demonstration of writing conformance tests with the T2C framework. (Vladimir Rubanov and Alexey Khoroshilov, 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.
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 (irc.linuxfoundation.org, #lsb) or reload this page for updates or alternate arrangements.