[lsb-discuss] LSB conf call notes for 2008-10-22

[Jeff Licquia]

Attendees: Ron Hale-Evans, Jeff Licquia, Stew Benedict, Mats Wichmann,
Kay Tate, Jiri Dluhos, Ted Tso, Jesper Thomschultz, Alan Clark, Alexey
Khoroshilov, Brian Proffitt, Russ Herrold, Robert Schweikert, George
Kraft, Dalibor Topic.

LSB 4.0 status.  Jeff: olver core tests?  Alexey: investigating the
issues.  If we see lots of failures, should be OK; there are a number of
test cases that are only slightly different.  Usually, we aggregate
those into a single failure when they're related.  If new things come
up, they won't be aggregated, so may take some analysis.  Memory
requirements are also an issue; are working on reducing those.

Jeff: also seeing issues with auto-run.  Some runs don't run all tests;
will work on figuring out why that is.  Alexey: DTK Manager can match
known failures; is that on the page?  Jeff: no; that page just reports
journal results.  Alexey: can we do that?  Jeff: is that info somewhere?
 Alexey: yes, there are reports.  Jeff: email me a pointer?  Alexey: sure.

Jeff: bug triage?  Mats: joke about taking a long time.  Jeff: Thursday
at noon Eastern still good?  Ted: IRC or call?  Jeff: could be a long
phone call.  Let's do IRC tomorrow.

Ted: how have we done with getting the distros trying things out?  Was
going to get Canonical to try; SuSE is working on them; anyone from Red
Hat?  Russ: no recent activity.  Ted: may need to ping RH.  Anyone have
contacts?  Jeff: could email the RH engineer from China.  Russ: may want
to contact higher-ups, too.  Ted: agree, but couldn't hurt to ping the
engineer, too.

Jeff: new signing keys.  Ted: has received them; will lock away.  Jeff:
who has the old master key?  Russ: if we have to ask, probably don't
have secure key management.  Jeff: not sure *I* know; do we have
knowledge of provenance?  Should we go ahead and regenerate the master
key as well?  Russ: I would recommend regenerating the master.  Ted:
trade-off; might want to change the master key yet again once we figure
out a better way to secure it.  Could always sign the
currently-generated keys with the new key.  Russ: publishing a roadmap
may avoid those hard questions.  "No known breaches, but an audit
reveals that our procedures have fallen behind the times.  We are
issuing new keys as an interim step, and will be rolling out a more
permanent procedure in the future."  Alan: could use our key signing
infrastructure if needed.  Russ: a number of partners could be used.
Ted: several people care, and can help; most won't unless there's a
breach.  Don't want this to be a blocker for 4.0.  Russ's roadmap idea
makes a lot of sense.  Could publish as a locked wiki page, plus a
pointer when we release.  Could also make this a general conversation;
defining general recommendations for all open-source projects.  Jeff:
short-term, need to write the roadmap, decide on the master key, upload
to the key servers.  Autobuilder key can be rolled out shortly; release
key won't be used until the first release candidate.

Jeff: build issues.  Tested using the autobuild process to do release
builds on one architecture (amd64); didn't see how those turned out.
Mats: looked fine.  Jeff: so will do next release builds with the
autobuild process.

Jeff: trial-use vote will be happening soon.  The delay is in figuring
who should vote, but should have that figured out shortly.  Results will
be sent to the list.