Russ Herrold (CentOS), Alan Clark (SUSE), Robert Schweikert (SUSE), Mats Wichmann (Intel), Jeff Licquia (Linux Foundation)
recap from last week -- goals: Modularization; uplift to gtk2, gtk3; include Python 3; dbus, sane, encourage Open Printing Group involvement; and a shift in temo to move closer to developmental distributions (and thus away fro the enterprise distribution trailing edge). Omit rpm re-work, and limit rpm work to LSB pain points, but largely ignore otherwise. Some tasking load discussion
XDG ... we have a bit in pipeline, but do we want to do more yet? inter-process communication (dbus) and auto-starting (systemd)
Multi-media, again ... has PulseAudio attained a stable, and useful API, so as so supplant ALSA. Commercial high quality use case users resist PA (and Bluez for similar, as well as having a high performant local incumbent, and also NIH reasons)
Gstreamer ... will it hit a formal 1.0 release and lock in their API
Robert, Mats: This new targets should be 'demand driven' before they are taken up (i.e., at LSB 5.0). We need specific domain experts interested in these, before we take up ... we have plenty on the plate already
Having a fairly clear goal list, on to Timeframing. Changing the passe of the LSB to have a tempo shifting away from the enterprise distributions, and closer to the 'bleeder' development distributions
Time budgeting, and then doing mid-course analysis to see what we ca hit within a defined timeframe to a tentative 5.0 release date. Can we look to prior efforts and get any comfort that we can timebox tasks. Mats: much of this uplift matter requires specific knowledge of library dependency trees, to be able to decide if a previously excluded dependency is still properly excludable. It may be useful to ping ISPRAS and talk this through
Robert: also need to do some basic research on each library. # of uplifts, any missing docs, missing tests, etc.
Jeff: for new specs, more work (docs, tests, etc.)
Modularization: what needs to be done?
Robert: need to report supported modules in the OS + tests for that reporting. May not need anything for app tests or SDK.
Jeff: so no sub-test runs on the distro side for just certain modules?
Robert: no, except for the test for the reporting framework. Install one module, check that that module is the only one reported, etc.