[lsb-discuss] LSB conf call notes for 2008-03-05

[Jeff Licquia]

Attendees: Stew, Sam, Jeff, Robert Schweikert, Kay, George Kraft, Dan 
Kohn, Alexey, Ted

SD West meeting summary.  Jeff: positive, stuff yet to do.  Web site is 
a concern; too focused currently on the process of creating the LSB, not 
helpful enough for users.  Ted: we are currently working on the web 
site, will provide a more polished and better experience for people just 
needing to use the LSB.  Workgroup stuff still there, but the prominent 
links will be to the end-user site.  Kay: would be delighted to act as 
reviewers.  Ted will send around mockups when the next set is available. 
  Will also be pulling in content from other sources: developerWorks, 
Novell articles, etc.

Jeff: also talked about tools.  Tool support is a higher priority than 
certification; using the LSB to solve specific problems is a way into 
LSB use.  Talked about better integration with the tools they're already 
using, use as a QA tool.  Ted: important to point out that we talked to 
a relatively small set of friendly vendors; no promises on exact task 
lists.  Need more info on what the priorities should be.  Jeff: we also 
pitched the ISVs on sending their app data to our database.  Ted: will 
follow up later in email, lots of good conversations.

High-priority tasks.  Jeff: currently on 2.6, upstream is at 2.12, SLES 
is on 2.8.  Is it still worth doing?  Robert: why not, if we do Qt 4.3? 
  Stew: can't do Qt 4.3 in 4.0.  Robert: should we continue to target 
current distros?  Ted: lag before ISVs want to target the new enterprise 
distros.  Robert: if this remains our goal for "prime time", which will 
limit the uplifts we can do.  Ted: tools more important than uplifts. 
Using LSB to replace the ancient build machine (building on Red Hat 9, 
etc.) and still provide binaries that work on multiple distros.  How 
many commercial apps are using the new dialogs?  Need to find out. 
Jeff: top feature in 2.10 is the new print dialog, which is the focus of 
a lot of effort in OpenPrinting.  Ted: in RHEL/SLES?  Jeff: no.  Ted: 
that's a problem.  Robert: how many ISVs need it?  Jeff: probably no 
one; still new.  Ted: trial use interfaces for uplifts of required 
modules?  Jeff: so is it still worth uplifting?  Cairo may be exciting, 
lots of apps seem to use it.  Ted: Database is still skewed to open 
source apps; need more info on proprietary usage.  Robert: how much work 
is it?  May not be worth arguing about if we can do it in a day.  Jeff: 
new tools will make it easier, maybe can think about.  Ted: who can 
comment?  Alexey: it is much easier, we expect that the most effort in 
doing a new library will be in other areas: docs, tests, understanding 
the quality, making decisions.  Ted: specs, tests?  Jeff: tests and docs 
are there for Cairo, haven't reviewed for quality.  Alexey: GTK+ isn't 
so bad, so Cairo docs should be OK.  Must engage upstream about what's 
appropriate to include.

SSL.  Jeff: shim layer.  Ted: make the shim as thin as possible and as 
close as possible to the 0.9.9 ABI, to make it easier to port.  Tell the 
OpenSSL people that we need a standard; they can commit to an ABI by a 
deadline, or we will standardize the shim library.  Need to make sure 
the distros are on board.  Dan: agree, we should reach out to OpenSSL, 
volunteers Jeff.  Ted: deadlines can focus people, enough time has 
passed that people are losing patience.  Kay: would be interested in 
that, also a tangible win for the LSB helping ISVs.  Dan: could we just 
bless the current API?  Ted: create the shim layer to look just like 
current OpenSSL, and port to RHEL/SLES versions of OpenSSL.  Present 
this to the distros, get them on board, then talk to OpenSSL.  Jeff: 
Mozilla NSS is an alternative, Red Hat is putting effort there. 
Drawback: completely different API, need to port.  May be better to 
treat NSS as a long-term strategy, and the shim as short-term, if 
OpenSSL doesn't cooperate.  Robert: still need to fiddle with their code 
with the shim?  Jeff: yes, but should be much less than the effort to 
port to NSS.  If the cost is very low, ISVs will weigh against the cost 
to keep maintaining OpenSSL.