maria-developers team mailing list archive

[Hakan Kuecuekyilmaz <hakan@xxxxxxxxxxxx>]

Arjen, all,

I like the idea of putting community developed storage engines into
our releases.

On 30.10.2009, at 21:35, Arjen Lentz wrote:

> Hi all, fellow Maria captains in particular (but naturally anybody  
> here can comment)
>
> 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.

It would not be loaded by default, but if you load the engine, then it  
surely will
have influence on mysqld.


> 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.

I would like to be strict in our release policy. Once we declare a  
release beta,
then we should be feature complete and no new features should be  
added. Otherwise,
there will be n "cool", "harmless", "trivial", and so on additions  
people may
want to add.

> 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.

The plugin infrastructure and storage engine interface is not as clean  
as one would
guess. Therefore a new engine adds new risks to the run time.

> 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 don't see any need for feature preview stuff. We will have at least  
a stable branch
and a development branch. I think that we aim for way shorter alpha to  
beta release
cycles; 3 to 6 months would be nice.

> (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)
>
>
> With the packages getting prepped now, I realise it's a tad short  
> notice. Don't feel rushed, but do please reply when you read this,  
> otherwise it might get lost in your email pile (I know my friends,  
> as I know myself ;-)
> Thanks


You are right, it would not matter, if nobody loads that engine. But  
people will
load it and it can lead to instabilities.

My answer is: no new features after beta.

Best regards,

Hakan

--
Hakan Küçükyılmaz, QA/Benchmark Engineer, Stuttgart/Germany
Monty Program Ab, http://askmonty.org/
Skype: hakank_  Phone: +49 171 1919839