Jeff Licquia (LF), Mats Wichmann (Intel), Robert Schweikert (Novell), Stew Benedict (LF)
Jeff: LSB 4.1 is continuing to progress. Almost everything is built, except s390, which is moving along slowly. I anticipate s390 will be done this week. Things are already being moved into the released directory. I have new release keys for 4.1
Jeff: Still owe Mats some content on ptrace, which should let us finish the spec
Jeff: On the PR front, I've talked to Jennifer and Amanda @LF and they're going to let us do our thing, probably a blog post
Jeff: Not sure there's much else to discuss on that front. New builds are sdk, python-test, appchk-python, desktop-test. Rest are the packages from RC1.
Jeff: Any other topics related to 4.1?
Mats: Can we talk about the bugs here, or take it elsewhere? It's a sort list
Jeff: Lets pull up the list. 15 open bugs, 6 of which are rollups.
Jeff: bug 1664 - ptrace, needs man page, hopefully today
Jeff: bug 2303 - pie executables, will probably get moved out, any actual spec work or just the tests?
Mats: There is spec work involved, by way of the database
lost my connection for a bit came back in the discussion on the open bugs on C++ long-double support
Jeff: t2c-runtime tests - I think we can just close it, unless someone has objections
Jeff: checkers - development vs production builds. This doesn't happen at the moment, so they probably have content about lsb-5.0. I'm not too worried about it at the moment, as it's only accessible from the command line. I think we can move it out.
Jeff: Any objections?
Mats: OK with me if you don't see an issue
Jeff: appchecker - segfault and too verbose bugs. I think we can move these out also.
Robert: I'm not sure tieing the tools to a particular release is all that useful anyway since they are version independent.
Jeff: Right, just attached here as this would be the next version independent release
Jeff: Last one is more c++ long-double stuff
Jeff: So 3 issues - ptrace, s390-elf, and massage the long-double bugs into a new bug for needed documentation
Jeff: Anything else for 4.1? Do we think we're in good shape bug-wise?
Mats: So what does this mean in terms of making the release?
Jeff: I think everything left is spec related
Mats: Was there something called RC2?
Jeff: It was my understanding we decided the changes were trivial and if the weekend build was OK, we'd go directly to final
Mat: Good shape for final translates to what for dates and actions
Jeff: s390 is the blocker right now
Jeff: Once that builds we should be ready to do the blog post or whatever PR wants
Jeff: Since we have a little bit of time, I'd like to talk about "upstream relations"
Jeff: I think we had come to the conclusion that we were at the point that we could get cmdchk and libchk run by the distributions as part of their QA.
Jeff: And then as part of post-4.1, we go back and go over our tests and make sure they are "golden"
Robert: Yes, we need to make sure that when the test is introduced, it can run clean
Jeff: So the next question is how to we relate to upstream as far as QA, how to get them to use our tests, and how are bugs propagated?
Jeff: If upstream is running the tests, and they file bugs in their system, how do we find out about it?
Mats: I've thought about it some, how we could feed into upstream from our bugzilla. We could use a flag, with another tool that reads the flag and submits upstream. The OS field is currently single.
Jeff: I've thought about it some. Sometimes we file directly upstream and then wait for things to trickle down into the distros. Perhaps we need to file upstream, then file with the distros when it's fixed.
Jeff: There are going to be exceptions of course, if a distro patches upstream and triggers the problem
Jeff: Do we want to change our process in this way?
Robert: I don't know what's best. For the community distributions, they're just going to mark it upstream. It would be well worth filing it with the distributions
Jeff: We have to workout which distros are affected
Robert: Currently, Stew tests the latest distro with the latest tests. So there are 2 moving targets
Jeff: maybe the answer here is just to muddle along as best we can, and try to get better at it
Jeff: I've thought about running tests against current development branches. Then we head things off before things even hit the distros
Robert: That gets us back to evangelizing the tests to upstream
Jeff: Perhaps adding another task to our list isn't practical
Robert: Perhaps we need to figure out a way to detach the tests from the framework and push them upstream
Jeff: One thing I've noticed from some of our tests we've implemented from upstream, is that sometimes when a test fails, the test just gets changed to accomodate
Robert: But then, if they notified us, we'd know and we have to change our tests and the spec
Jeff: Might be an interesting goal for the year to pursue this more aggressively than we have.
End of Call