Re: [Maria-discuss] Information for release notes
Also posting this message to maria-discuss for those that might be
interested in the changelog, but are not subscribed to maria-developers.
On Thu, 24 Sep 2009 15:19:19 +0200, Kristian Nielsen
Hi Daniel On 27/09/2009, at 2:24 PM, Daniel Bartholomew wrote:
Using the contents of the list, I have created a Changelog page on the wiki:
http://askmonty.org/wiki/index.php/Manual:MariaDB_5.1_Changelog
I organized the page into two sections: Features, and Bug Fixes. I also added links to the pages in the manual which exist for the changelog entries refer to.
Fabs.
Stub pages for the manual are easy to create:
1. add a link to the new page to http://askmonty.org/wiki/index.php/Manual:Contents 2. click on the new link 3. enter the following text into the new page: {{stub}} 4. save the new stub page
To get things going, I created the following new stub pages for the manual:
http://askmonty.org/wiki/index.php/Manual:Mysql_client_--abort-source-on-err...
http://askmonty.org/wiki/index.php/Manual:XtraDB_storage_engine
http://askmonty.org/wiki/index.php/Manual:Character_Set_Conversion_performan...
http://askmonty.org/wiki/index.php/Manual:CHECKSUM_TABLE_performance
Other stubs may need to be created, but I don't know which of the remaining topics need documentation or not. For example, does the entry about MariaDB NOT supporting NDB need it's own Manual page or not?
I'd say just create, you can always change things over time - the MySQL manual evolved also with sections appearing, merging, splitting and also disappearing. The cool thing about the wiki is that you can easily redirect a deleted page to a relevant new one. Re NDB... the NDB in the source tree may not be production capable, but it's technically functional. Builds for Ubuntu tend to include NDB, and it actually works (I've used it in training classes). So that's already the real world. MariaDB may also consider a magic merge solution with the actual NDB 6.whatever tree, as mixed setups (NDB and other engines) are perfectly common and sensible in various deployment scenarios. You then need the up-to date InnoDB stuff and binlog/replication fixes, as well as the server-side NDB infrastructure with enhancements and bugfixes. In short, a merge - at least that's what I can tell, someone please correct me if I'm wrong. I appreciate it might be a difficult thing to do.
Any contributions to the above stubs are *very* welcome. Any contributions to any of the other refman pages are likewise welcome:
http://askmonty.org/wiki/index.php/Manual:Contents
Henrik> Could the list itself be a basis for a changelog document and Henrik> then we make release notes into a more human readable document? Henrik> I thought that was your intention yesterday on IRC?
The changelog page is a good compliment to the release notes page. The changelog is brief and is presented as a series of bullet points. The release notes page is longer with items presented as paragraphs in a more readable way.
For this, think about what a user or support/DBA person needs: will upgrading to version N break anything? Any changes required or things to look out for? If you can organise the info in such a way that that's clear and easy (smart grouping, for starters), that'd be fab! Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org
Arjen Lentz
Re NDB... the NDB in the source tree may not be production capable, but it's technically functional. Builds for Ubuntu tend to include NDB, and it actually works (I've used it in training classes). So that's already the real world.
MariaDB may also consider a magic merge solution with the actual NDB 6.whatever tree, as mixed setups (NDB and other engines) are perfectly common and sensible in various deployment scenarios. You then need the up-to date InnoDB stuff and binlog/replication fixes, as well as the server-side NDB infrastructure with enhancements and bugfixes. In short, a merge - at least that's what I can tell, someone please correct me if I'm wrong. I appreciate it might be a difficult thing to do.
When I discussed NDB with Monty back in February, we basically agreed to focus our efforts elsewhere than NDB. That is the reason it is not maintained in MariaDB, rather than any particular technical issues. NDB is actually the part of the MySQL server I know best (I worked on it as a developer for two years), so we do have the skills required to maintain it. But my own impression is that there just is not the interest from the community for this. Yes, I see many that show interest after hearing of NDB, but few (if any) that actually start to use it once they learn of the difficulties and limitations. As far as I understand, Sun/MySQL is not really maintaining NDB in 5.1 either, at least when I was there 1 1/2 year ago all efforts went into the -telco versions, which are based on a separate source tree from MySQL 5.1. Maybe these days they are even based on MySQL 6.0, the development tree used to have this base. So it seems to me that maintaining NDB as part of MariaDB would be too much effort, at too little gain. Of course, if this assumption turns out to be wrong, we can revisit the decision. - Kristian.
Hi Kristian On 28/09/2009, at 8:16 PM, Kristian Nielsen wrote:
Arjen Lentz
writes: Re NDB... the NDB in the source tree may not be production capable, but it's technically functional. Builds for Ubuntu tend to include NDB, and it actually works (I've used it in training classes). So that's already the real world.
MariaDB may also consider a magic merge solution with the actual NDB 6.whatever tree, as mixed setups (NDB and other engines) are perfectly common and sensible in various deployment scenarios. You then need the up-to date InnoDB stuff and binlog/replication fixes, as well as the server-side NDB infrastructure with enhancements and bugfixes. In short, a merge - at least that's what I can tell, someone please correct me if I'm wrong. I appreciate it might be a difficult thing to do.
When I discussed NDB with Monty back in February, we basically agreed to focus our efforts elsewhere than NDB. That is the reason it is not maintained in MariaDB, rather than any particular technical issues.
NDB is actually the part of the MySQL server I know best (I worked on it as a developer for two years), so we do have the skills required to maintain it. But my own impression is that there just is not the interest from the community for this. Yes, I see many that show interest after hearing of NDB, but few (if any) that actually start to use it once they learn of the difficulties and limitations.
As far as I understand, Sun/MySQL is not really maintaining NDB in 5.1 either, at least when I was there 1 1/2 year ago all efforts went into the - telco versions, which are based on a separate source tree from MySQL 5.1. Maybe these days they are even based on MySQL 6.0, the development tree used to have this base.
So it seems to me that maintaining NDB as part of MariaDB would be too much effort, at too little gain. Of course, if this assumption turns out to be wrong, we can revisit the decision.
Ubuntu has been building with it, which is at least useful for training and education. If we build without, we break backwards compatibility, and that prevents uptake by users. Like it or not, we have to be a superset - we only build this on Ubuntu, but nevertheless we need it. It has to at least work build and start. It does not have to be pretty. Re NDB in general, I used to share your opinion, however more recent developments in the telco tree make it usable for a broader audience. (running on Sean Pringle's opinion for that - you've met. Works for OQ now) That might make a merge-in from the telco tree interesting to look at, not right now (just time considerations). Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Exceptional Services for MySQL at a fixed budget. Follow our blog at http://openquery.com/blog/ OurDelta: enhanced builds for MySQL @ http://ourdelta.org
participants (3)
-
Arjen Lentz
-
Daniel Bartholomew
-
Kristian Nielsen