InfiniDB gets the release process right
InfiniDB has a sensible Enterprise/Community release process, which seems similar to what I suggested for MySQL. Its simplicity also stands in stark contrast to MySQL’s new release policy, which is hard to understand and has been confusing people.
Hi,
I don’t see how they stand in “stark contrast” at all. As the InfiniDB release process (as described in link above) describes maintenance releases, and omits describing process for how new features are developed, and the MySQL link above describes “Development Cycle”, i.e how focuses on how new features are developed and omits description of maintenance releases.
/Jonas
Jonas Oreland
5 Feb 10 at 8:22 am
One thing that is good about MySQL community is that everyone is entitled to have an opinion :)
The development cycle stands for what the title says – it describes how we develop the software, and has little (see below) to do with enterprise/community differentiation and frequency of GA releases.
The connection between the development cycle and the release process or policy is in the quality guarantee. By stating and adhering to certain rules (such as the QA has the primary say whether to accept a feature or not, not the release manager, for example) we ensure that the main tree does not accepts features that are alpha quality. By chopping the features into sizable chunks, and frequently stabilizing the trunk we have the opportunity to “go GA” at any milestone, i.e. when the amount of useful functionality has reached a critical mass.
When working on the document, I had a lot of trouble ensuring that this agenda stays unchanged. I did not fully succeed — many people were frustrated with our release policies, and took this opportunity to give vent to their frustration. Notice, if you look at the MySQL university session referred to from the wiki you’ll notice the title creep — the development cycle is referred to as “release cycle” :(
One of your links refers to Antony’s confusion over our release numbering. Well, how to number releases is *not* an artifact of the development cycle. Funnily enough, initially it was, but then our Sun ubergods decided they’d like to have a say. Since then engineers refer to milestones using flower names – Betony, Celosia, Dahlia — just to avoid confusion and avoid the stupid argument whether addition of deserves a major version number increase.
Speaking of your criticism of our 3 year old attempt to differentiate — well, hello, we haven’t had binary or source code differentiation of the server for over a year (maybe more, I’ve not been watching closely), I don’t see how it could come unnoticed. I’m sure that you’re aware that one of the persons responsible for the 2007 enterprise/community differentiation is now a VP at InfinyDB :-p.
Konstantin
5 Feb 10 at 5:51 pm
It hasn’t gone unnoticed that there’s no difference between MySQL Community and Enterprise. I blogged about that when it was formally announced, too. I fear that might be reverted soon. But at the same time I have a feeling Oracle will do a better job at that than MySQL did.
Maybe I didn’t read closely enough. But seriously, I am a software engineer and I basically decided it was too complex to try to understand fully. My voice might not be educated, but perhaps that in itself has meaning. I have just been shaking my head incredulously as things have gone from confusing to more confusing. This isn’t a criticism of you personally — I am sure you really tried to make things sane, and I can get a hint of the politics and bureaucracy that must rear its head around things like this. I don’t have the patience to tolerate that — I definitely wouldn’t last long in your job.
I’m well aware that Robin is at InfiniDB, and I’ve been a perhaps unjustly harsh critic of him at times. I criticized InfiniDB for dragging their feet on releasing the promised open-source code. Then they released it. Now it looks to me like they’re doing some things really well. Among other things, I’ve seen evidence of a focus on instrumenting their product to make rigorous performance optimization possible, and now this. If they keep going, I’ll be at risk of becoming a fan.
Xaprb
6 Feb 10 at 1:07 am
Thanks Baron for your post and input. We do appreciate all feedback (both positive and negative) that we get. I’d like to respond to a few of the comments made.
First, thanks for the comments on our omission of how we plan to release and label new versions in our last blog entry (the one that kicked off this thread). I’ve posted a new entry that describes our intentions on that front and welcome any input and revisions that the community thinks is necessary. You can read it here: http://infinidb.org/infinidb-blog/more-on-infinidb-release-intentions-and-practice.html. Also let us know if you would like more details in this area.
Next, yes indeed I was one of the proponents of having more of a Fedora/RHEL model for MySQL some years back. Marten always encouraged us to try new approaches to things, and to me, having faster community releases with small new features that folks wanted sooner than later seemed good to do. But then we hit technical glitches with producing the builds and some in the community voiced their opinion that it wasn’t the approach they’d prefer, so things were changed again. Sometimes you never know until you try.
Lastly, regarding criticism: I’ve only been at Calpont since September 2009 so I haven’t been a part of every decision made (but pretty much am now). I think Baron’s criticism of the failure to release the InfiniDB source code as promised in the Spring of last year was warranted. A good community holds a project/vendor to the claims and promises they make and when those promises aren’t kept – and there is no “head’s up” communication of the circumstances that have caused the ‘miss’ – then a deserved poke in the eye should be expected.
Thanks again and let us know what more we can be doing at this time.
Robin
8 Feb 10 at 9:46 am
Thanks Baron for your post and input. We do appreciate all feedback (both positive and negative) that we get. I’d like to respond to a few of the comments made.
First, thanks for the comments on our omission of how we plan to release and label new versions in our last blog entry (the one that kicked off this thread). I’ve posted a new entry that describes our intentions on that front and welcome any input and revisions that the community thinks is necessary. You can read it here: http://infinidb.org/infinidb-blog/more-on-infinidb-release-intentions-and-practice.html. Also let us know if you would like more details in this area.
Next, yes indeed I was one of the proponents of having more of a Fedora/RHEL model for MySQL some years back. Marten always encouraged us to try new approaches to things, and to me, having faster community releases with small new features that folks wanted sooner than later seemed good to do. But then we hit technical glitches with producing the builds and some in the community voiced their opinion that it wasn’t the approach they’d prefer, so things were changed again. Sometimes you never know until you try.
Lastly, regarding criticism: I’ve only been at Calpont since September 2009 so I haven’t been a part of every decision made (but pretty much am now). I think Baron’s criticism of the failure to release the InfiniDB source code as promised last year was warranted. A good community holds a project/vendor to the claims and promises they make and when those promises aren’t kept – and there is no “head’s up” communication of the circumstances that have caused the ‘miss’ – then a deserved poke in the eye should be expected.
Thanks again and let us know what more we can be doing at this time.
Robin
10 Feb 10 at 8:58 am
Robin, your comments got trapped by Akismet — my apologies. (I only check the spam list infrequently.) Thanks for your comments!
Xaprb
19 Feb 10 at 11:25 am
As owner of a small company with perhaps more limited knowledge of all the solutions, I must comment here that Calpont are certainly doing something right.
We tried Veritica first, and found the whole process and support system quite poor (for our more amateurish level) whereas Calpont’s support system, even for Community members is ridiculously good. They are keen to help and don’t assume that everyone is a pro.
Apart from the performance gains seen, we are finding that understanding what Calpont are up to, when and what they are planning to release and fix, and their timekeeping is simply fantastic.
svekaria
24 Mar 10 at 5:26 am