What constitutes an RC release though, in my mind, but I really want to know what you think, is software that is really 100% feature complete. There may be, but hopefully there aren't, even any major bugs to iron out. In short, it is "A Candidate to Release", and as close to GA as you can get. I have not seen this rule broken much, really.
With MySQL 5.5.7, this is an rc, as was the previous release, 5.5.6, and this time there is a really major feature introduced between these two release, pluggable authentication. And before I go on, let me stress that this feature per se is not what I am questioning here, quite the opposite, this is a very useful feature.
What I am questioning though is:
- Why is MySQL introducing new major features in an RC release, even in between 2 RC releases? This means, if I am not mistaken, that this very important feature (authentication deal with security, mind you), that it might go live (the C is for Candiate) without having been beta tested?
- What made MySQL 5.5.6 a Release Candidate? What I mean here is that if we assume that this major new features was conceived, written and performed in just a few weeks between 5.5.6 and 5.5.7, MySQL knew that 5.5.6 wasn't feature complete, and hence in no way a release candidate (C is for Candidate, if you had forgotten that little fact).
- Why does MySQL insist on having major important changes to the security setup be tested the least in the server before GA? Fact is, what MySQL is telling us here is that there may not be any testing at all (as 5.7.7 is RC (where C is for Candidate) which means is could possibly be GA.
To be clear, I will stick with 5.5.6 for now. Not 5.7.7 or even 5.5 GA for a while, until I have tested that pluggable authentication is secure and solid for production use. I really want 5.5, and I am not alone, so I do not understand why MySQL had to screw around with this. I do understand why pluggable authentication should go into MySQL, for sure, but not in 5.5 or at least not in the midst of a RC cycle.
/Karlsson
Who is not saying he will now change to Postgres. Nope, I will not not act stupid. And watch me run with 5.5.6 for a while yet, I will not be alpha testing MySQL security in a live production site, no way, José.
15 comments:
Karlsson,
It is and has been for quite some time that all parts of MySQL are not at the same level of stability. More specifically, pluggable parts of the server can be at different levels of stability. This allows us to drive towards "faster" release cycles without delays imposed by features which are used only by a minority of the users and which will also not affect the majority. For example, a unstable storage engine will in no way affect you if you don't use it.
For example, you can look at the Linux kernel, which in a similar manner to MySQL, has dozens of different subsystems and modules. Not all of them are at the same level of stability, yet this doesn't preclude a stable release. A modular design allows one to declare the stability of core (essential) parts and work towards a release.
MySQL should be able to introduce features even in a GA release in case it does not affect the other parts of the server.
As for pluggable authentication, it has been in the works for quite some time. Yet, I suspect you won't be able get much out of it without coming up first with a plugin :-)
Also, some relevant links.
The new development cycle:
http://forge.mysql.com/wiki/Development_Cycle
WL#1054: Pluggable authentication support
http://forge.mysql.com/worklog/task.php?id=1054
Davi, Linux doesn't work that way. There are parts of the kernel that are marked as experimental, sure. But the decision as to what is going to be at what stability level designation is decided well before the final release. Linus doesn't push remove the experimental label on section between RC builds. Its not that mysql has different levels of stability that concerns Kalsson ( and myself), its the process of doing it.
Water,
Which part of the process causes concerns to you? Note that the development cycle does not allow what you suggested either.
> Linus doesn't push remove the experimental label on section between RC builds.
BTW, yes, he does. I've seen him merge removal of the experimental tag even in a rc8. What matters is the actual stability of the code, not whether it is declared early or late in the RC cycle. Otherwise, its just a oversimplification. What matters is the real stability, not when it is declared/merge, right?
Davi!
Three questions / issues then:
1) This change is very core to the server, as it deals with security, which makes it a bit scary, at least to me.
2) This change entails not only additions to the server (which is pretty much OK I guess), but also major changes to core code. I.e. the existing authentication (which is NOT in a plugin) has been "Reimplemented [...] as plugins". Which all in all means that important things (authentication) which is NOT in a plugin has been changed.
3) Not only has things been added through a plugin, which, again, should be OK, but the Plugin API in itself has been added mid-RC. And really, adding a Plugin-API is beyond just adding a Plugin to an existing API.
/Karlsson
Mind you, this is the same authentication functionality that used to be part of MySQL from early on, just converted into a plugin.
The pluggable authentication code has been part of MariaDB since version 5.2.0, released in April. They just declared 5.2.3 stable today. So it's OK for them to include it, but not for Oracle/MySQL?
I just do not think that introducing new features and reengineering in the midst of an RC cycle helps. If MariaDB folks want to do that, that is their call, but I don't think that is serious either, but they didn't do it in the middle of the cycle at least.
As for just moving the same code from the server to a plugin makes you wonder my MySQL stuck with two different InnoDBs in 5.1, both of them GA then.
And for this just being the same old code converted to a plugin, well on top of that, we sure have the authentication API itself, right? And by the way, this is apparently not just the "old" authentication code, there is the Proxy capability and the new client side options.
/Karlsson
Right, our version was added at the alpha step. And MySQL implementation, although based on ours, was significantly modified (for example, according to bugdb, new bugs were introduced, that weren't part of the original implementation).
I fully agree! See Bug #58139
Karlsson,
Whether it is introduced earlier or late, or one year ago or next week, is not of much relevance. What actually matters is the stability of the code. As a engineer, I prefer to approach this kind of decisions from a technical point of view. One can look at the code and debate risks, perform QA, etc. According to our development cycle, it can go in almost at any time as long as it is stable (which does not mean bug free). Again, our release candidate are just signaling work towards a release. It is not the beta, alpha, etc process.
We are stuck with two versions of InnoDB in 5.1 because the plugin stability level wasn't tied to the server and both were incompatible. I haven't seen users complaining about that as long as this is explained. Having options in this case is not a bad thing.
Would you rather they put it post-GA?
I understand your concern, I'm just not sure how I feel about it, because if new features should be beta tested, then we'd have to wait a *while* for 5.6 to be beta'd with pluggable authentication.
And one of the biggest complaints about MySQL in the past was that features that were release-ready had to wait (the most public example is Jeremy Cole's SHOW PROFILE/SHOW PROFILES feature, which had to wait years to get into the codebase).
I worry about major changes in general. And I'd rather them put a major change in an RC than in a post-GA version.
I, for one, hope that we get lots of large unstable features in GA. It will help sell support contracts and make my life more interesting.
Sheeri!
Yes, I too would rather have major features in RC rather than GA. On the other hand, I'd much rather have them in Alpha possibly Beta. And in this case, I'd rather be open about and say this really is Beta. But maybe that's just me. But if we accept that we can introduce major changes to a release just about anywhere in the release cycle, what is the difference between Alpha, Beta etc.
Also, the real problem is that there is just too much time between GA releases, and it seems we can agree on that. And that makes features slower to end of in a GA release for sure. But in my mind, the solution to that particular problem is not to have new features in just about any release, rather, it the solution must be to have fewer incremental GA releases.
In this particular case also, we are talking about some rather core features. And Guiseppe has already pointed out, there are already flaws with this, and this is the second RC!
/Karlsson
While I generally agree with Davi (from the engineering point of view), exactly this case with pluggable authentication is different in my point of view.
It affects the Client/Server protocol, which is or should be sacred, and as long as changes are not documented for the public here
http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol
or there are notable bugs in the protocol implementation (like this one http://bugs.mysql.com/57442)
it should have not made it to the release.
I'd also prefer if the network protocol stayed compatible, for MySQL and forks, and that includes pluggable authentication of course.
Otherwise it would be hard, if at all possible to write a client that works for different incarnations of MySQL.
Post a Comment