maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Hakan Kuecuekyilmaz <hakan@xxxxxxxxxxxx> 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.