Jeff Licquia (LF), Stew Benedict (LF), Alan Clark (Suse), Robert Schweikert (Suse), Mats Wichmann (Intel)
Jeff: Status on SDK - packages are built, need to be signed and repo/tarball gen, announcement. Will do some testing. Should be done sometime today. Then the 4.0 refresh can proceed.
Jeff: Comments on SDK issues?
Jeff: On FHS, I've been setting up infrastructure, in refspecs, version control, mail-list, wiki page, workgroup page. Have a draft message out for review, will send out to a number of places.
Mats: May want to send to the the old spam collector list.
Jeff: Good idea. Also sent a courtesy email to Chris Yeoh, don't have addresses for Rusty or Dan
Jeff: Have set a target date for July 1. Anyone have reason to believe we can't hit that?
Alan: What's the list of things to do again?
Jeff: Call for participation, get any new bugs filed, triage all the bugs and fix what we choose are important, issue draft spec, release
Jeff: Any other questions on FHS issues?
Jeff: Other major thing I wanted to cover today is the runtime profiles proposal
Jeff: One of the things that seems to be happening, is that the second proposal, rather than an alternative modularization approach, becomes a feature in our tools. With the idea you could build with a subset of LSB
Jeff: Am I totally off base here? Can the 2 co-exist? Should we stop talking about runtime profiles as an alternate modularization proposal?
Robert: I'm OK with that. We need to figure out resources need to accomplish the work, then prioritize things
Jeff: Since it's just a feature, we can decouple from the release if we choose to. Do it after 5.0, or before?
Robert: Yes, it's independent. But what we deliver is the spec, and the tools that go with it.
Jeff: Any other opinions on this?
Jeff: OK. So the question becomes what does this look like in practice? We basically already have this in app-checker. What other tools need it? How does it get implemented?
Jeff: We've been thinking of this mostly in terms of the SDK. Want to give developers the opportunity an active approach to targeting the distros they want.
Jeff: Do we think there's more to it than that?
Robert: I don't think there's more to it, just question the value/whether ISVs will use it
Jeff: So getting back to what this would look like, what other tools would get changed?
Stew: I don't see the value in distribution testing, to see if a distribution is compatible with itself
Jeff: Would there be value in seeing if 2 distributions are binary compatible with each other?
Robert: We have that more or less now, with LSB. I see this a sucking up a lot of someone's time for something we don't have demand for. Resistance to LSB has been in part to our changing the compiler
Jeff: Gcc has plugins, what if we did an LSB plugin instead of the lsbcc wrapper
Robert: Basically the same problem, now we have to convince the ISV to load the plugin
Jeff: OK. So then the question becomes, are there other less intrusive methods to make the case for the LSB SDK?Seems like we go to ISVs, get feedback, try to fix the problem, and then still get resistance. Maybe we need more feedback
Jeff: So it seems like this would mainly be an SDK feature, not necessarily tied to an LSB release
Jeff: On the distribution side, I will ask this question. We've talked about being more aggressive, targeting the community distros more than the existing enterprise distributions. Do we want to be able to selectively disable new tests for interfaces only in the new libraries?
Robert: We already have that, we can test for older versions of LSB. It's LSB or nothing.
Jeff: Any other opinions?
Alan: I agree with Robert
Jeff: I know there's some resistance to the runtime profiles. I just want to flesh out the details, discuss it, and if we decide to shelve it, that's fine. Just want to give it a fair shake.
Jeff: Any other comments on runtime profiles?
Jeff: I'm at the end of my agenda? Anything anyone wants to discuss?
End Of Call