Hakan Kuecuekyilmaz <hakan@askmonty.org> writes:
Where do you need some help for our release?
Looking at http://askmonty.org/wiki/index.php/MariaDB_5.1_TODO, seems it is currently mostly the mysql-5.1.38 merge. One thing that would be useful is to try some additional testing on top of what is already in Buildbot, as there is quite a lot missing... some of this might be better done after the merge is pushed though, but you could start preparing. Maybe you could check what additional test suites/tools are already available that could be used? Stuff like unit tests, mysql-test-run --ps-protocol, additional test suites... One thing in particular is to prepare to test the actual release. Releases are built in a two-step process, first build a source tarball, and then build the binaries from those sources. Buildbot builds directly from a bzr checkout. And Binaries are run from the installed location, while Buildbot runs the tests from the build directory. It would be really embarrassing if some major part of our binaries were released completely broken due to some file or something not being included and no testing at all done :-(. So we could use some tools to test stuff like this. Eventually we want this in Buildbot of course. Concrete suggestion: 1. Testing on installed mysqld. Run `BUILD/compile-dist && make dist`. Unpack those sources and run `./configure <options> && make && make install`. Run `make clean` (to catch bad references into build dir). Then run the testsuite on the installed mysqld. 2. What we used to call "smoke test" at MySQL: Build a binary package, then install it on some machine and see that it can start and stop. Basically testing the package stuff (directory structure, mysqld_safe, ...) which is not covered by the test suite. See http://askmonty.org/wiki/index.php/MariaDB::PackageBuild for how packages are built currently.
My idea to work on and look into it: Currently we have around 10 test failures on Mac/PPC. If you want, I can start looking into those failures. Where should we report failing tests? I would like to open a bug for each test failure.
Currently we seem to be using Launchpad for bugs. However, it does not sound all that useful to blindly report one bug per failure. Probably some of them are related with same root cause. If you can identify those root causes, then one bug each makes sense (maybe this is what you meant). Otherwise a single bug probably, just noting that someone needs to look into it when time is available. - Kristian.