And it has failed the testuite on every single build slave. I’ve filed BUG#45605, BUG#45630 (together with a patch), BUG#45631, BUG#45632. There is also rpl.rpl_innodb_bug28430 test failure which I didn’t report as I don’t yet have enough details about the build slave.
At the moment our setup works as follows: there is lp:~maria-captains/maria/mysql-5.1-testing branch, which our copy of lp:mysql-server. We periodically pull from the main tree into our copy, it’s a manual process. Buildbot watches for pushes to our copy and runs builds/tests after every push. The results are publicly available here.
UPDATE: Sun people say their pushbuild is nearly green (=all tests pass, on nearly all platforms). This is very odd, as our build slaves are nothing special - about half of them are recent Ubuntu installs on most popular architectures.
This is what’s happening at the moment. 5.1 tree doesn’t pass the tests, both Sun and Monty Program fix that, and the fixes are different. Here is a Valgrind warning which was fixed twice:
my fix my fix (correct link) made the involved mysys function to do what its name implies while Alfranio’s fix changed the replication code not to call that function anymore.
Besides the Valgrind warning, we observe failures for rpl_trigger.test and query_cache_28249.test (if you follow the links you’ll have to grep for test name. Buildbot has some room for improvent). I get these failures in maria-5.1-table-elimination tree. The problem is that when the failure is random (the query cache one is) or when I get it after merging from main, I cannot easily tell whether
- the problem is in my new code
- the problem is in MariaDB
- the problem is in the original MySQL
- and they are not aware, or
- they are aware and there is no fix yet
- they are aware and have the fix in some team tree (merges from team trees to main can happen as rarely as once a month)
I think we’ll have to take the main branch and have our Buildbot run tests for it, too. We’d like to add all publicly available trees (when analyzing random test failures it is the more runs the better), but our small population of build slaves (volunteers welcome!) will not manage to do that many test runs.
This isn’t news anymore - it has been over a month - but it would be odd not to mention this all, so here it goes: at the start of May I’ve left Sun Microsystems and joined Monty’s company.
The setup at Monty Program AB is quite similar - we have an IRC channel (#maria on FreeNode), a mailing list, bazaar trees on launchpad, Worklog and a Buildbot installation. It’s actually more open than at Sun/MySQL. At Sun, everyone is on internal IRC, external public can only see a subset of Worklog (the biggest problem with it is that it’s not possible to subscribe to changes), and their Buildbot-like system (it’s called PushBuild and looks like this) is not visible to the outside public.
There are actually very good reasons why an external person might want to look at pushbuild. Everyone doing development (if you count Summer of Code students and engine developers, that’s a lot of people) or just trying to use the newest features will at some point want to get the latest source from bazaar repository. And the problem here is that the trees get broken every once in a while, and when you are pulling the sources from launchpad it is nice to know what you’re pulling. You can run the tests yourself, sure, but that takes time. And if you do take time to run the tests, then if you see a failure you won’t know if Sun/MySQL is aware of the problem, whether it is repeatable on any computer or you need to report your OS/compiler/configure flags/test run parameters and so forth and so forth.