| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Kristian, Hakan, On 04/11/2009, at 10:40 PM, Kristian Nielsen wrote:
Arjen Lentz <arjen@xxxxxxxxxxxxx> writes:packages before they will try things. If 5.1 binaries had had PBXT plugin sitting there, lots more people would have tried it earlier, filed bugreports and feedback, and Paul would have been where he is now much quicker. With MariaDB pulling it in it's ok now, but it's just a darn waste and pity of the earlier time.I also think this is a very clear description of an important point. ++
thanksThe PBXT thing has irked me for years now, and while PBXT is now in MariaDB it'll be great to see a general solution to the issue.
(On the practical side, since it's essentially separate it would get added during the source tarball prep in the builds, so no action required inside the maria tree)It is _much_ better to get it inside the tree.Everything in MariaDB development revolves around the bzr tree. Development,buildbot, testing etc. etc.If it's not in the tree, it will be broken by some MariaDB change. And you will discover it only during release work. And we will have to delay the release or omit ograph from that release, and generally waste lots of time andeffort. And you will be on your own to fix things.If it's in the tree we will catch problems immediately and have the longestpossible time to plan and fix.Of course it's your code so it's your call in the end. But I just don'tunderstand why you would _not_ want it in the tree. Is there some specific concern(s) that we could perhaps address?We can use bzr merge-into (like with xtradb) so you can still maintain astand-alone tree.We accept storage engines like this into the tree without any copyrightassignment, just the GPL 2 is fine.I know I'm preaching in-tree and Buildbot to you all the time :-). But it really is the way development needs to be done to scale to the level we wantand utilise the limited resources we have.
I'm fine with having OQGRAPH in the MariaDB tree, on a merge-into basis, but I do feel it's important to address all the issues here:
OQGRAPH is very new. since it's not a general purpose storage engine the maturity curve is theoretically different; but Open Query does not want to get some special treatment for whatever reason. Whatever set of "rules" we decide on here should apply to all plugins.
I also appreciate the comments made by for instance Hakan, who feels that once a tree is in its beta phase, no new code (not even non- loaded plugins) should be added. While those plugins would not be installed by default, they'd still be quite present. So this is a perfectly valid position to take.
Since we're building packages, it's possible to make say a mariadb- xxxx package that contains just the plugin xxxx. In that scenario, it does not actually matter whether the plugin comes from the mariadb tree or not, it would be compiled against it anyway. To make this decently workable, we need to sort out the "need an entire mariadb source tree to build the plugin" problem.
We filed a wishlist bug for this, https://bugs.launchpad.net/maria/+bug/470580 which also includes a patch by Antony Curtis. It creates a mysql- glob.h during the build process, which we could put into a mariadb- plugin-dev package.
Then, some mariadb-xxxx packages can be build in the main mariadb build, and some can be separate. It also allows developers to work on plugins sanely. It cleans up the entire dev environment for this - it's not 100% pretty as it's a nasty big include, but it's a good step given the current mess.
Now to return to the original trail, perhaps Hakan would be ok with plugins being in separate packages, then there is no chance someone could have code installed that is not necessarily production ready, if they haven't explicitly chosen to install it. The problem I'm trying to resolve here is still essentially the PBXT issue. It's really important that new plugins get tested so they can feedback and bugreports, and that only happens if they're available in easy binary form. However, having them available for the current production version (or anything >= beta) as well as alpha stage versions, is important. The cycle from alpha to final is still sufficiently long that this will hinder the development cycle of new plugins. So, if we can agree on a way that allows new plugins to become available in binary form to beta or even final versions of MariaDB, I think that would be a great win and really invigorate the plugin ecosystem.
Hakan, what do you reckon? Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: packages for MySQL and MariaDB @ http://ourdelta.org
| Thread Previous • Date Previous • Date Next • Thread Next |
