maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Hi,

With all the european MariaDB people stuck in California, there is an
unexpected opportunity for extra face-to-face meetups. So today I had the
opportunity to enjoy lunch at a nice sushi place in Santa Clara with Henrik,
Timour, Peter, Vadim, and Sanja. Here are a couple of key points from the
discussion:

1. We need to consider carefully how we handle keeping the MariaDB product
stable for production use. Peter had the point that the critical thing is
avoiding behaviour change. This means that if some version of MariaDB works
sufficiently different that the user need to work on their application to
upgrade, it is a blocker to adoption. Different in this context means
different from any previous version of MariaDB, but it _also_ means any
difference from MySQL!

I think I can see that this is actually more important than mere
bugs/regressions. If a bug slips through, we can fix it, and if we can fix it
quick enough the user may even be happy with us.

But if the behaviour is qualitatively different (and such difference can not
easily be turned off), that is a real problem for the user.

We discussed a lot around this for the subquery optimisations. This is a
"scary feature", as it has the very real potential to change execution plans,
occasionally for the worse.

As Timour pointed out, there is for each new optimiser feature a server
variable to enable/disable it. So we need to very clearly state in the release
notes, under "upgrading to MariaDB x.y", that there are optimiser changes, and
give the exact list of variable settings that will make the optimiser run in
"MySQL 5.1 mode".

For other features this is simpler. For storage engines, just disable the
engine and it will have no impact. For possibly replication plugins, again
don't use the plugin and there should be no difference in behaviour. But
again, we need to very carefully think about this and communicate/document
this.

For other features again we might need to re-think this point, making sure we
do not change behaviour in a non reversible way.

I think this is a good observation from those with a deep knowledge of the
operational side of Databases.


2. On a note related to stability, I think we need to carefully avoid the
mistakes from the MySQL release model. Basically, we need to have regular
releases (6-12 month cycles). This is all-important! Much more important than
any single feature, however big. We must _never_ push a feature into a tree if
it is not ready. Better make an empty release!

So this means it is actually wrong to say that subqueries will be in MariaDB
5.3. That should not be the plan. The subqueries will be in the first release
made after they are ready. Which maybe 5.3, may be something else.

I think we very nearly made the same mistake with 5.2. We had a feature list,
and while some of them were "rolling", we also had features that were decided
in advance that they _must_ be pushed at a certain date. I strongly believe
this is wrong. We should have made _all_ features rolling.

Unless we are extremely careful with this, sooner or later there will be
sufficient pressure that we will push unfinished stuff into a release, causing
_all_ of that release to be a failure. By waiting with the unfinished feature,
only that feature will "fail", and by being careful with releases, the next
release will be close anyway.

(Yes, "finished" cannot mean bug free. But it can mean "as good as we can
reasonably make it".)


3. The final point I took from the discussion was related to version
numbering. We in the MariaDB team of course know that we rock, and that we
will change the world tomorrow, or at least as soon as planes will take us
back to Europe :-). But the reality is that for now, we are an appendix to
MySQL with MariaDB 5.1 and 5.2.

It thus can be argued that this should be reflected in the version numbering,
to avoid confusion. Peter made the point that he would like to see MariaDB 5.1
and 5.2 versioning be made so that it is clear that there is a base MySQL
version plus some well-defined set of changes. (This is how XtraDB release
numbering works).

So we currently have MariaDB 5.1.44, which is equivalent to MySQL 5.1.44 plus
some set of safe patches. But MariaDB 5.2.0 is actually the same, just with
some additional, also safe patches.

So rather than go to MariaDB 5.2, we could imagine something like this:

    MariaDB 5.1.44-1       Current MariaDB 5.1.44
    MariaDB 5.1.44-2       Current MariaDB 5.2.0
    MariaDB 5.1.44-1.1     In case we need to do a bugfix for 5.1.44-1
    MariaDB 5.1.46-1       Next time we merge MySQL 5.1.46 into MariaDB -1
    MariaDB 5.1.46-2       Next time we merge MySQL 5.1.46 into MariaDB -2

I need to think more before I fully make up my mind about these points one way
or the other, but I think these are in any case interesting points to
consider.

 - Kristian.