The Linux Foundation, parent organization of the Linux Standard Base, will hold its annual Collaboration Summit April 6-8, 2010 in San Francisco. Given the budgetary restrictions many participating organizations are still facing this year, the LSB workgroup will hold a Face-to-Face meeting co-located with this event, including the day prior, April 5. The first day will be focused more on internal LSB affairs: planning activities for the workgroup and so on. An LSB session will be held during the main Summit period to focus more on external issues: presentations on applications of the LSB, testing technologies, etc. As has been the case at recent meetings, the F2F portions will be relatively informal, following the "unconference" format, in other words, while there will be a set of requested topics ahead of time, the agenda will be determined and evolved interactively during the meeting. A brief bullet-point summary will follow.
Remote participants can call in to the usual conference call line (605-715-4920, #512468). It will be open for both Tuesday's and Friday's sessions.
Day 1 (Tues)
Day one was a relatively unstructured discussion of various topics. Attendance was disappointinly low, only two participants on site and two on the phone. This fact was material for some of the discussion.
Postmortem for LSB 4.1
- Did we accomplish the major goals we set out?
|Get rid of App Checker unnecessary output when looking at native apps.
||Made some progress.
||Did not go as far as we wanted. Problem statement/goal was not precise: what consitituted completion?
|| This was owned by a resource which became unavailable. Some of the ELF "noise" was improved; the "single instance" bug didn't get closed. Also, need a regression test to make sure the shared lib bug in App Checker doesn't come back. Make a better statement of problem, clearer goal for "LSB Next".
|Test suite for ALSA
||Accomplished. Well-defined goal.
||Coordination issues; Stew and ISPRAS ended up doing the work. Some work wasted (spec markup).
||This will be a topic later in its own right. Need to re-evaluate the framework, change how we structure future projects.
|Printing spec enhancements
||Accomplished. Well-defined goals. Some test expansion (gtk-print-dialog appbat test)
||No implementation help from OpenPrinting. Insufficient test coverage expansion to cover the new interfaces.
||Deferred. External help from OpenPrinting did not materialize; issues with distro support anyway.
||All symbols got in.
||No additional test coverage.
||The symbol list was written to meet other goals, which were themselves not as closely tracked. Still, improved our symbol coverage, which is always positive.
||Infrastructure is better than it was.
||Jeff is still the single choke-point. Still struggling with reliability. Still can't "throw a switch and do the release". Too much pain along the way.
||Also its own topic later. Ended up being a lot more work than anticipated.
||Test coverage did not advance with the specs.
||Some question about whether we advanced as far as we could have. GTK+ is on 2.24; we're now on 2.10. RHEL 5 as the trailing release may have forced us to hold back. Should we re-evaluate our targets?
Summary: 4 goals met, 1 goal deliberately dropped, 2 goals partially met.
- Focus on systematic progression was lacking in parts of the project. Lots of distractions pulling team off the tasks. Maintenance work (fixing bugs): also valuable/necessary, but doesn't show a march towards release goals.
- Project management was almost completely missing. A specific person is one approach; however the OSS model of using the bugtracker collectively is also okay if it's driven relentlessly, which did not happen (bug meetings petered out, completions not followed up on, etc.)
- Don't schedule important milestones (like release candidates or final releases) in December. For a few releases now, non-technical considerations have gotten in the way.
- Can't do everything. Need to set expectations more appropriately (bugfix release schedules, version-independent stuff with new features, new spec releases). External factors meant considerably less resources (man-months) were available than anticipated across the full schedule.
- Still need "Product management" - the external coordination with stakeholders still doesn't just happen because we have a mailing list.
LSB 4.1 Schedule:
- We were late.
- Scheduled release date of December 15, actual release date March 3.
- RC1 was due December 1, actually released January 24.
- Last-minute problems discovered right before important milestones.
- LSB 4.1 took almost two years, too long for what was delievered.
- Announcements did not go out as scheduled for various reasons.
- Question: did the lack of a link to an external event cause us problems?
- We've decided in the past not to worry about an external date, rather release when ready
- However... perhaps sharper release focus if date tied to a conference, media event, or a distro release, or some other clear externally determined date
- Problem: enterprise distros certify (only) to "current" LSB. Moving them forward is a problem; they tend to be conservative once certified. i.e. Distro X certifies to LSB Y, we design (Y+1) so that X is still fully capable of running it, but for X to actually comply with (Y+1) requires some sort of upgrade (keystone/dependency pkgs). This isn't usually a technical problem, it's a distro policy issue (Mats: the "Product Management" issue applies here, nobody to work this with distros so it's gone from hard to impossible).
- Should the LSB become more of a "leading standard"? Focus on the directions of the fast-moving community distros & pick up the new standards in anticipation of next enterprise distro releases. Pitfall: moving too fast, making mistakes? Perhaps "leading" is too much; go a little ahead, but not much.
- Could result in longer LSB spec release cycles.
- Problem: we're already seen as not very active; longer release cycles will make this worse.
- Solution: tie more of our activity to version-independent stuff. That is, keep delivering functionality, even if spec delivery slower.
- App Checker
- Dist Checker
- Increase test coverage
- Distro/upstream compliance checking
- Other possibilities.
- It's OK to not be able to do everything, but we need to state ahead of time what we're going to do, instead of overpromising and underdelivering.
- It's OK to get pulled off to other projects, as long as that's communicated.
- May be the case that some LSB tasks are higher priority right now.
- Steady and consistent progress is the key. Don't let bugzilla slide. Would intermediate goals help (see version-independent comment above)
Goals (from 2010):
- Better autobuilder.
- Jeff out of critical paths.
- "Flip a switch" release process; clear, documented, mostly automated.
How'd we do?
- New autobuilder: yes
- On balance: much better.
- Complicated build process in general vs. buildbot problems.
- UI is better.
- Locking issues still exist.
- Big resource sink with no big "payoff" (didn't make us release faster, probably made us release slower - this time)
- Jeff out of critical path.
- Not much progress
- Process sent to Stew; he could probably muddle through it if necessary
- Stew still needs release keys.
- "Flip a switch"
- No progress, outside of Stew's notes.
How do we do better?
- Why is what we do so complicated?
- We make choices that make this worse.
- Some things are about "organic growth"; needs pruning/refactoring (see above on "payoff" problem though)
- Example: tetj lives in misc-test where it grew up (checkers all use), but now used by other projects which thus need to check out misc-test - to copy a couple of files. Split out somehow?
- "Multiple check-out" problem: we check out a branch, then from branch's package directory we do "bzr export" thus checking out again. From the initial checkout, only the files in package/ are used.
- How do we make these things better?
- Refactor package-subdir builds to build the original tarball w/o a separate checkout.
- List all "unclear dependencies" somewhere: where one project pulls individual things out of other projects, and set a project timeline/resources to fix some of these.
- To an extent, infrastructure work can be an "ivory tower" thing; making the infrastructure work perfectly may have to take a back seat to getting an actual release done. (Example: 4.0 appbat issues now.)
- Do we need a project to make the documentation less manual?
- Package repository generation should happen automatically from staging.
- Bundles lower priority than repos: not important for non-released packages.
- Other topics:
- LF system updates.
- More IRC services (MeetBot, ChanServ)
- Convert to git?
- What would a vibrant LSB community look like?
- We're not there now: participation numbers are way down, basically three bzr committers left, one of whom is scaling back participation; leaving two LF employees. Mailing list traffic is low. IRC conversation is basically "internal".
- We need to figure out how to proceed, the current state of affairs is not satisfactory
- We need to figure out how to get to a point where a community can (re-)form around the LSB and people can easily contribute
- An OSS community only works when people's needs are being met
- The SDK is the inflection point: this is how you use the LSB to improve portability
- People in the real world aren't even evaluating (or aware of?) the SDK. (See Mozilla Firefox blog post.)
- Can we promote the SDK?
- One view: if it doesn't actually work to solve people's problems, it won't be looked at.
- Another view: no one is even evaluating the SDK and declaring it not up to the job.
- We should pick some small set of high-profile apps (possibly just one) and get them building under the SDK, and then promote that success.
- Bugs tend to get their attention.
- One success story: LSB init scripts.
- Barrier to entry: do the tests give meaningful results?
- Need to find people who can integrate these things at the distros, like Robert at openSUSE.
- Barriers to entry
- Are the tests useful? (bad test failures, etc.)
- Is it easy to contribute?
- Is it understandable?
- "Developed behind closed doors": perception fed by some of the previous problems.
Test Framework Issues
- Test framework
- We are not getting any of our tests upstream
- Do we need to look at designing/implementing a new framework that can be pushed upstream?
- It is difficult to contribute to the current test effort
- Our tests need to be useful outside of our LSB-specific requirements.
- FooUnit is the standard.
- Easy to use
- Little overhead.
- We need our testing to be as easy as FooUnit in order to be successful.
- Hook into FooUnit?
- Most are structured for this: harnesses, test runners, etc.
- Add the ability to run the test in "LSB mode".
- We also need to smooth out the process of integrating upstream test suites into ours.
- Mostly ad-hoc; usually driven by some crisis or new upstream integration into LSB.
- We also now host "abandonware" test suites; do we need a process to phase out such suites?
- Experience with alsa-t2c: lessons learned, how to do differently, etc.
- Not too difficult once you're familiar with the framework.
- Markup requirement is tedious.
- Doesn't give advantages in helping people work together.
- Can't say that T2C or AZOV tests give better feedback for failures than the other tests.
- "Requirement 2 failed" instead of "Expected x, got y".
- Can be more informative, but not any easier or better with T2C vs. other test harnesses.
Talks at Conferences
- "Developing Portable Applications" (with LSB tools)
- Should still be primarily LSB-focused, but not to the exclusion of general techniques
- Fill a need people have.
- Value of LSB Distribution Tests (at Plumbers, or some similar conference).
- In past, Mats/Michael Kerrisk discussed a Plumbers talk on Linux doc. that would show relationship between manpage and LSB spec
- Robert can probably go to LinuxCon in Vancouver; Alan might be able to go to some of the conferences in Europe.
Work Past Tuesday
- What are the key features to examine for uplift/addition candidacy (FutureTarget, UpliftTarget tables)
- gtk/glib/pango, Qt, GL, C++, dbus
- Note this is not "commit to do" but "agree to study"
- The Elephant in the Room: is there actually a sufficient need for an LSB-Next?
Day 2 (Friday)
| 9:00am - 9:15am
|| Welcome, introductions, overview. (Jeff Licquia, Linux Foundation)
| 9:15am - 10:00am
|| State of the LSB. (Jeff Licquia) A summary of where we are and where we're going. Results from Tuesday's session will also be discussed.
| 10:00am - 11:00pm
|| Joint session with the OpenPrinting workgroup. See their page for location and call-in details.
| 11:00am - 12:15pm
|| Modularization part 1. A new approach to a modular and useful LSB. Presentation.
| 12:15pm - 1:30pm
| 1:30pm - 2:30pm
|| Modularization part 2. How to get there; LSB-Next.
| 2:30pm - 3:30pm
|| Other standards and initiatives: FHS, LANANA, etc. Align with new POSIX?
| 3:30pm - 4:15pm
|| Current portability concerns: (a) "stale": init/systemd/upstart, advent of GTK+ 3.0, etc.; (b) "missing"
| 4:15pm - 4:30pm
OpenPrinting joint session
Jeff presented on the changes in LSB 4.1. The CUPS refresh was sorely needed, and met with a lot of enthusiasm.
On the subject of request for the next version of the LSB, there are three broad areas.
- This is in the same state as for LSB 4.1.
- Depending on other priorities, we may have more time to put into this one for the next version of the LSB.
- Hot-button for a number of reasons.
- Printing-specific: userspace is notified via a D-Bus signal when a new printer is attached.
- More difficult; this is considered a kernel interface.
- There are already difficulties with udev and other utilities not cooperating on printer discovery.
- Perhaps the udev folks would be willing to compromise and standardize some subset of things? (Side note: it was discovered later that udev provides command-line utilities that are intended to be the stable interface to udev.)
- Other minor areas: there are some interesting APIs in CUPS 1.3 and following, but nothing quite as significant as the new APIs introduced in CUPS 1.2.
- Proposal in the presentation needs some more work.
- The proposal may not actually solve any ISV issues, for a lot of work.
- Much of the benefit we already have via Linux App Checker (although the new scheme would also propose to add a lot more data)
- Proposal appears to lead towards describing the "current state of affairs" for ISVs, therefore the LSB value proposition changes.
- Conceptually, changes from "one port" model (which some claim has failed) to a "give as much porting assistance as possible" model - expanding the trend started by the app checker using DB distro data
- Alternate proposal: Make current modules externally visible
- A distribution must still certify to all of LSB, i.e. provide all components
- Distribution must provide mechanism to install all off LSB, but also should provide mechanism to install individual LSB components, such as LSB-Core for example.
- Only distributions that can certify to LSB as a whole can be considered LSB certified, compliance with some components only does not constitute LSB certification.
- The App Checker will tell ISVs after analysis what components of the LSB are required by the application
- ISVs can thus better check their requirements during installation
- With modularization one should be able to answer questions as follows:
- What components of the LSB are installed?
- What components of the LSB are available?
- Be less trailing than we are today
- Enterprise distros certify to the version of LSB current at time of distro release, generally they do not update their certification, even if that is possible. Therefore, targeting current Enterprise distributions for LSB next makes little sense and put a disproportional strain on the LSB.
- Target community distros, these distros are a good indication for technology expected in the next enterprise distros at release.
- The next version of the LSB should almost certainly be 5.0. (We will break compatibility with previous releases, back to LSB 3.0)
- Removal of Qt 3.
- A distribution will no longer need to provide Qt3 to be LSB certified, however, any given distro vendor may still provide Qt3.
- Potential deprecation of:
- Python 2.x
- Gtk+ 2.x
- Deprecation means that these parts of the specification are still required, i.e. while any given part of LSB is deprecated a distribution must still provide the functionality for this given part.
- Potential uplifts and additions:
- Add Gtk+ 3
- Add Python 3
- Add DBus
- Uplift OpenGL
- Uplifts related to gcc
- Evaluate effort and weight benefits of uplifting requirements that are expected to be deprecated:
- Gtk+ 2.10 to Gtk+ 2.24
- Python 2.x to 2.7 to specifically include "Python 3 migration functionality"
- Modularization should be part of LSB next
- Radical modularization proposal may de-emphasize the LSB proper.
- Alternate proposal introduces new high level query functionality with LSB work group potentially turning into upstream for distros
- Potential trial use: systemd
- Monitor systemd vs. upstart development while LSB next is under development.
- Should make sure we are clear on our roadmap going forward; will there be demand for LSB-Next?
- Timeline will be longer than before, most likely.
- Must decide the future of the LSB on conference calls on a strict deadline. (proposed 2-3 month at the most)
- Messaging must be precise: deprecation, not removal.
- Needed by systemd, since /var may not be mounted at startup for /var/run.
- Only used by the system; apps should stay in /var/run.
- /usr on separate partition is no longer possible?
- Again, caused by systemd.
- Need more info.
- Should restart the FHS process and come out with a revision fixing bit-rot.
- Separate infrastructure from the LSB: own list, bugzilla, etc.
- bugs.linuxfoundation.org is already the bug tracker.
- Maybe a new list on lists.linuxfoundation.org?
- sysvinit/upstart/systemd decision deferred
- Old-style init scripts will be supported for the foreseeable future.
- With a little more time, a "winner" may emerge between upstart and systemd.