Hi Kristian Thanks for a good summary. I think my main, high-level takeaways were: I wasn't aware that even our optimizer work can be controlled by variables. I get for new features, but there's also refactoring going into 5.3. I guess we cannot guarantee 100% identical behavior with MySQL? One thing you didn't mention, but came up in this discussion as well as many others: The one killer feature people will be looking to MariaDB for will be the replication API, and promise of better replication. (more throughput, synchronous multi-master and easier to manage/failover). Subqueries will make MariaDB a better RDBMS, and possible a better migration target from the old proprietary databases, but replication is interesting to current install base - especially high profile users like Percona customers. On Wed, Apr 21, 2010 at 1:29 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
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". ...
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.
I think everyone *says* they agree with above. You're right that we did drive 5.2 a bit differently. I think it is ok for us at MP to set some goals for ourselves as a team, then push to achieve those goals. But ultimately, if some feature is not ready in time (and even "in time" can often be a flexible concept as needed) then it will be dropped and considered for future releases. Btw, in the hypothetical case that we have nothing at all ready for a release, then there is no point in releasing every 6 months. So it is still valid to think of the process from the opposite point of view saying: This is the work we have in front of us now, we'll finish this, then we have a new release. Reading my own text below I guess I'm only saying that real life is often more flexible than just being one or the other. But ultimately - yes, we should do precisely what you describe.
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.
This was an interesting remark by Peter. While I understand the point, and it is a valid point, I instinctively dislike the suggestions above. What we do for 5.1 is good. MariaDB 5.1.44 is based on MySQL 5.1.44. This is very easy to understand and remember. I do believe that having the same scheme for 5.2 is still an option: MariaDB 5.2.44 would be based on MySQL 5.1.44 (this is called 5.2.0 in reality). This is not as intuitive as it is for 5.1 series, but cleaner than what you suggest above. Con: this scheme will only work as long as MySQL keeps leaving holes in their releases. henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc