maria-developers team mailing list archive

[Henrik Ingo <henrik.ingo@xxxxxxxxxxxxx>]

Noting also Hakan's and Alex' comments...

On Fri, Oct 30, 2009 at 10:35 PM, Arjen Lentz <arjen@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
tel:   +358-40-5697354
www:   www.avoinelama.fi/~hingo
book:  www.openlife.cc