LSB conf call notes for 2008-10-22
Submitted by LSB List on Wed, 10/22/2008 - 16:00.
Printer-friendly versionPosted to the lsb-discuss mailing list by: Jeff Licquia
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.
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.