Noting also Hakan's and Alex' comments... On Fri, Oct 30, 2009 at 10:35 PM, Arjen Lentz <arjen@openquery.com> wrote:
We'd like to include the plugin for OQGRAPH engine in the 5.1 packages we're just about to build. It would not be pulled in like the xtradb/pbxt engines, but be compiled separately and not loaded in by default (people will have to do INSTALL PLUGIN) so that as long as it's not loaded, it can have no influence on the running of mysqld.
Someone would of course have to look at the OQGRAPH engine itself to have an opinion on "worthyness". That is not something for me.
The rationale is this. From the experience with PBXT, people really want/need binaries/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.
Since 5.1's plugin infrastructure still requires a plugin to be compiled against close to exact the original mysqld source, the only way to ensure that is to compile them from the same source at the same time, next to eachother. So that's what I'm proposing.
Yes. We have some ideas how to enable an even richer ecosystem of plugins than what is possible now. Adding storage engines is fine, but potentially people could start producing hundreds of plugins, and we don't want to have on giant RPM with hundreds of megs of plugins. But that is for the future, for now what you say makes sense.
Nonsense like the feature preview builds that Sun/MySQL did just make no sense in the real world, people can't use that. So while sticking new plugins in a future version like 5.2 appears sensible, it doesn't actually help in getting the code out there and used which is of course the only way to get feedback and bugreports. The ability to have plugins distributed but not loaded is the key here, it allows us to get stuff out and those who want to try it can, without destabilising anything for those who don't.
I'm not sure I understand how you meant this to happen, but as I see it we have been working on building even "what we have now". So until that is working, the answer would be a firm no. (I was on vacation last week, but I see we have a beta out now for some platforms, so I take it your proposal is meant for the "what you'd like to do next" discussion, so possibly we are in full agreement here.)
(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)
Everything that is needed to produce the MariaDB builds must exist in the maria launchpad tree (except for the VM images where the build happened, but these should also be available). Things must not have been "pulled in from here and there". The other thing, why I'm writing this at all, is that you are probably not aware that our plans for 5.2 is for it to be a really short release cycle, following essentially immediately upon 5.1. So the idea since August has been to not touch 5.1 more than "make it work" and put all new stuff in 5.2, and even for 5.2 things have to be 95% ready, no major new features built from scratch, that is for 5.4. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc