Minutes Apr 27 2011
Jeff Licquia (LF), Stew Benedict (LF), Mats Wichmann (Intel), Alan Clark (Novell), Robert Schweikert (Novell)
- Status of 5.0 proposals.
- LSB 4.0 refresh.
Jeff: 4.0 refresh and SDK refresh. We added gcc 4.5 support to sdk and I'm concerned whether this is working
Mats: I'm building things on my system where I couldn't before
Jeff: How about c++ support?
Mats: I can try to build something
Mats: Looks like t2c-cpp fails
Jeff: So perhaps we revert the 4.5 support for the sdk refresh until we can fix it properly
Jeff: Some things are missing yet in staging, need to get those caught up. Appbat needs to be built yet
Stew: Pushed a brown paper bag fix to olver today, that needs a rebuild Jeff: Looks like everything but s390 built this morning. I throttled that system back in response to usage comments from IBM. Will have to manually trigger those.
Jeff: I'll try to get the sdk release out before the end of the week, then build the rest of the 4.0 stuff
Jeff: Anything else on refreshes?
Jeff: On the 5.0 proposals, I haven't done much on updating the wiki info. I know Robert did some work on the other modularization proposal
Jeff: My question on this proposal, do we need subcomponents? Does it make things more complicated? Would it be better to drop lsb-gui/lsb-desktop and just have lsb-gtk/lsb-qt?
Alan: So break the components into a finer granularity?
Robert: One concern is if we wind up with too many components, things become too big. Question is where do you draw the line? I think we should stick to a reasonably small number of components. We'll have to discuss it further and get to what we're all comfortable with.
Alan: If we have subcomponents, we still have to label them, so you still get a big list
Robert: If we have the toplevel, then the ISV can just specify "lsb-gui", and not worry about what makes up gui
Jeff: From the distro point of view, they have to provide it all, and build up that hierarchy in their "lsb" package(s)
Robert: From a dependency point of view (packages), it becomes simpler to maintain
Jeff: So the concensus on submodules seems to be ISV won't care (in the sense they can pick whatever level of granularity works for them) and it may actually be easier for distros
Alan: They're going to care with respect to how much trouble it becomes to describe things
Jeff: Do you think more modules/submodules is more trouble for an ISV?
Alan: No, if we break it down right
Robert: We can't be afraid of getting things wrong. Our infrastructure has to be robust enough that we can move things around easily
Jeff: But will it be easy to move things? How will an ISV handle it if a module moves?
Robert: We'll have to have a transition period when things move, similar to the deprecation policy, so people can adapt.
Robert: modularization will let us appeal to a broader spectrum of ISVs, where they can granularize as they wish
Jeff: Think I'll let this rest for a bit and let people think about it and comment. Possibly the ISVs on the list will comment. Next step would be to propose this to distributions and see what they think.
Jeff: In the meantime I need to try to stimulate some discussion on the other "runtime profiles" proposal
Jeff: We have 2 proposed talks for LinuxCon in August. A 45min presentation and a BOF. Talk would be about writing portable applications using the sdk and app checker. Hopefully the BOF will get some feedback
Jeff: Also had lanana.org disappear on us (domain expired). Question came up as to who should be in charge of these things. Came to the decision that the domain should probably be transferred to LF
End of Call