← Back to team overview

maria-discuss team mailing list archive

Re: maxscale 2.0 bug fixes


Hi Kaj

Yes you did answer all my questions. Thanks for that.
I disagree about point 2, precisely the "reasonable number of years" a server software should be supported. Even if a software is very old (say MySQL 5.0 for example) it is very possible that new security holes are found. That's why customers using servers/versions which reached their EOL should definitely upgrade to a more recent version. (yes there are exceptions, but I'm talking about the general case)
Let's get back to your example: on 2019.01.02 MaxScale 3.0 could be out and GA. Should we expect the typical user to be ready to upgrade? Based on my experience, definitely not. They need time to decode, plan, test, etc. The possibility that 2.0 will be discontinued (or almost discontinued) immediately after the Change Date is scary, and your answer doesn't provide any guarantees that this won't happen.

So, as much as I appreciate your honest answers, and as much as I like the software itself, I am seriously concerned. And also, let me add that I don't like to use a software that is not (yet) open source. I totally understand the problems explained by Monty in his blog post, but I don't like the solution you've found.

However I am glad to hear that you don't have plans to do the same changes to connectors and storage engines. If I may give an advice, maybe the Foundation should officially "protect" that software to dissipate any doubt.


Mer 17/8/16, Kaj Arnö <kaj@xxxxxxxxxxx> ha scritto:

 Oggetto: Re: maxscale 2.0 bug fixes
 A: "Federico Razzoli" <federico_raz@xxxxxxxx>, maria-discuss@xxxxxxxxxxxxxxxxxxx
 Data: Mercoledì 17 agosto 2016, 20:23
 Hi Federico,
 Thank you for your questions. 
 Wed, 17 Aug 2016
 08:15:33 +0000 (UTC) Federico Razzoli <federico_raz@xxxxxxxx>:Hi
 I see that MaxScale 2.0 will not be open source
 until 2009.01.01. I have some questions.
 1) I expect next releases to fix bugs, including
 critical and security bugs. When will these versions be open
 1. Fixes to 2.0 will be in 2.0.1, 2.0.2,
 2.0.3 and so on. All of these will become "GPLv2 or
 later" on 2019-01-01.
 At some point MaxScale 2.0 will be open and 3.0 will be
 released but not open. When a software exists in both an
 open and a closed source, I expect the open form to be
 low-quality. This applies to all examples I can think of. I
 will feel a bit better if you could explain why you will
 maintain 2.0 for a reasonable number of
 2. At some point (say: 2019-01-02), MaxScale
 2.0 will be "GPLv2 or later", but another release
 (say: MaxScale 2.1 or MaxScale 3.0) will not yet be
 "GPLv2 or later" but still BSL, correct. MaxScale
 2.0 will by then have gone through a list of bug fix
 releases. I don't expect there to be many bugs left in
 the MaxScale 2.0 code on 2019-01-02. In a way, what I am
 saying is that the period until the Change Date is already
 "a reasonable number of years". 
 What the *exact* situation is on 2019-01-02
 depends on how many new releases we will have by then. At
 any rate, we want to grow the user base of MaxScale. We are
 interested in large-scale adoption. There won't be much
 adoption if we don't fix bugs for a "reasonable
 number of years". 
 All in all, on 2019-01-02, MaxScale 2.0 will be
 bug-wise of high quality and the only reason to use 2.1 (or
 3.0 or whatever) instead of 2.0 will be the added
 functionality on top of what 2.0 has. So MariaDB Corporation
 has a high motivation to add desirable
 functionality. 3)
 From my understanding part of MariaDB code belongs to
 Oracle, thus cannot be closed-sourced by you. But what about
 connectors and some storage engines? Do you plan to change
 their license?
 3. Correct, MariaDB Server cannot be closed
 sourced by us. We have no current plans for changing
 licenses of any connectors or storage engines. 
  Thanks in advance for your
 Did this answer
 your questions?
 Kaj Arnö, Chief
 of Staff