[lsb-discuss] LSB conf call notes for 2009-07-29
jeff at licquia.org
Wed Aug 5 07:37:26 PDT 2009
Attendees: Jeff Licquia, Stew Benedict, Kay Tate, Jiri Dluhos, Brian
Proffitt, Mats Wichmann, Dennis Gilmore, Ted Tso, Russ Herrold, Dalibor
Topic, Alan Clark.
Brian: sent out the email last week regarding classifying MediaWiki
content. Best suggestion so far was Kay's suggestion for
classification. Will be implementing those. Note that changing
classifications will change URLs. Ted: this is for pages being moved
only? Brian: yes. Un-moved pages will stay in something like a wiki.
Public-facing stuff is what we're focusing on. Getting wiki content off
the corp site is the main driver. Ted: maybe we should limit MediaWiki
via robots.txt to start this? Brian: don't think we need to do this.
Can live with the problem short-term. Can let the search engines figure
out things on their own. Redirects work for searches for older content.
So much content, though, that it's only a band-aid. Jeff: migrating
off MediaWiki for wiki? Brian: David doesn't care if we stay on
MediaWiki. Will need to move the URL, though. Ted: we should start
using robots.txt once the URL moves. Brian: right. Ted: so the issue
is to declare the taxonomy "baked"? Kay: to be clear, mainly wanted to
add two things to the list. Ted: little concerned about reviews or
descriptions going into development, and then wanting to split it later,
which would require URL changes. Can we split a category easily?
Brian: easy, in the sense that we can create a new topic and move
things. Redirects can be done for a while, but those will break once
they go away. Ted: what's the downside to a too-full category besides
finding things? Brian: that's basically it, and it's not even a major
issue. Can do tweaks so really popular content isn't buried. Good
internal searching helps too. Ted: tagging? Brian: that's independent
of the taxonomy, so can be used to rearrange things to an extent. Ted:
tags might end up being the way to rearrange things. Worried because it
might become hard to find stuff in the long term. Brian: could do the
categories as tags instead of as formal categories. Disadvantage is
that things all live in the same "bucket". Ted: suspect that long-term
lots will land in development, not so much in the others. Jeff: other
disadvantages to using tags? Brian: not really, because we can use tags
in our top level. Having the category in the URL is better for search
engine optimization. URL space is "heavier" as criteria, but the tags
still count for something. If we need this flexibility, it's not a
serious problem. Ted: could use categories as an initial "best guess",
then switch to tags if we need to reorganize. Adding brand-new
categories is basically easy? Brian: yes. Ted: only addition may be to
have "for distro" section. Kay: "for isv" too. Ted: development and
testing? Kay: certification. Brian: can just do now. Jeff: so, start
with certification, and move to tagging if needed. Brian: will send
this on, now just need lists of content to move. Ted: could we have a
way of flagging content that needs to be moved and cleaned up? Some
content may be poorly formatted or out of date before made public.
Brian: maybe use a Google spreadsheet to do this. Please send
suggestions for content to migrate, and will put the initial list up.
LSB 4.1. Jeff: what's been done? Mats: we've figured out the stuff for
OpenJDK. Other than that, nothing visible seems to have happened. ALSA
is about tests, which hasn't made any progress. Jeff: elephant in the
room; any ideas on moving ALSA forward? Alan: from the silence, maybe
just take it as it is. Ted: or, at least, no magic resource is going to
appear. Are we willing to lower our standards for ALSA? Russ: same
issue as Java: not free. Ted: the idea is to make an LSB-compliant
OpenJDK. When will we get the list of interfaces, and when will we be
able to review? ALSA comes up because we know that OpenJDK will need.
Dennis: is ALSA going away? Jeff: other APIs are around, but no leading
contender. Plus, ALSA is the only common denominator. Ted: asked
another way, will ALSA be going away? Dennis: think the limited
PulseAudio implementation will be all in enterprise distros in a few
years. Ted: if we were to standardize only the subset? Dennis:
Fedora's JDK works with PulseAudio. Jeff: also, will they truly be
going away or just de-emphasized? Ted: if we believe that ALSA will
continue to work whether through direct access or via a compatibility
layer, isn't that OK? Dennis: in theory, the Pulse compat layer could
go away. Ted: api compatibility. Jeff: is sydney further along?
Dennis: checking recent changes in Fedora, should be further along.
Jeff: ALSA is still the lowest common denominator, should keep an eye
out for a better common denominator. Ted: is there a place where we
should discuss this? Dennis: maybe need to speak with the JACK and
PulseAudio upstream. The site says that the API is release-worthy.
Should maintain ALSA support for quite a while, most likely. Ted: can
we shrink the list of interfaces to those that are supported by
PulseAudio? Jeff: we may be able to.
(Asked for on the call: the bug with interface requests for OpenJDK is
More information about the lsb-discuss