From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-December/010266.html | 162 +++++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-December/010266.html (limited to 'zarb-ml/mageia-dev/2011-December/010266.html') diff --git a/zarb-ml/mageia-dev/2011-December/010266.html b/zarb-ml/mageia-dev/2011-December/010266.html new file mode 100644 index 000000000..0a54a7c8c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010266.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] MariaDB 5.5.18 on cauldron tonight + + + + + + + + + +

[Mageia-dev] MariaDB 5.5.18 on cauldron tonight

+ Thomas Backlund + tmb at mageia.org +
+ Thu Dec 8 00:58:04 CET 2011 +

+
+ +
Maarten Vanraes skrev 7.12.2011 22:31:
+> Op woensdag 07 december 2011 20:38:16 schreef Thomas Backlund:
+>> After Alpha2 I guess we need to discuss this on a council meeting to
+>> get a decision for Mageia 2.
+>
+> fine, i don't see the need of why to have a council meeting wrt this though...
+>
+
+Sorry for being unclear, I was just pointing out that if we cant agree 
+on the ml, council has the power to decide.
+
+> lemme know when there _IS_ a good moment to submit
+>
+
+Fact is... I'm very much interested in mariadb, and given Oracles track 
+record, I suspect soon mariadb will be the only real choice.
+And since I know who upstream is, I have no problem switching...
+
+
+The thing I reacted against is the bad timing and even worse test planning.
+
+You suggested to push mariadb in the middle of a big kde upgrade, wich
+pretty much means half part would have been built against mysql and the
+rest against mariadb... (yes I know it should work tecnically, but...)
+And then you suggested that if it does not seem to work we pull it back 
+out 2 days later -> meaning no real time to test, and messing it up
+even more... thats not how you do proper testing/qa...
+
+
+There must be a _way_ better longterm plan to get people to really
+think about it...
+
+
+So here is what I suggest:
+
+
+After Alpha2 ISOs are relased to the mirrors:
+1. announce the upcoming push on -dev ml to remind people
+2. push mariadb to core/release obsoleting/replacing _all_ of
+    mysql.
+3. rebuild _everything_ that normlly builds against mysql to make
+    sure it builds correctly against mariadb and still works after
+
+
+Now for thq QA / testing part:
+1. we use mariadb in Alpha3 (planned 2012 Jan. 12) and keep
+    fixing any bugs that might show up.
+2. around ~10 days before Beta1 (planned 2012 Feb. 21) we evalute
+    the situation... if it still seems to work, keep using mariadb
+    for Beta1
+3. final call: 1-3 days before version freeze (planned 2012 Mar. 7)
+    This it the point of no return... Here we decide if we go mariadb
+    or mysql for Mageia 2. Whatever we decide at this point is not up
+    for discussion anymore after this, as version freeze will be
+    enforced (with small reservation for KDE/Gnome release schedules)
+    This way we have Beta2 (planned 2012 Mar. 15) and RC (planned
+    2012 Apr. 10) to flush out any problems we might get by reverting
+    to mysql.
+
+
+And to be more specific about all needed testing for mariadb:
+- testing all apps built against mariadb
+- testing by creating all kinds of databases in mysql, and see
+   if mariadb is capable of upgrading/supporting them
+- testing if sql clients still work when accessing (remote)
+   mysql servers.
+- for those that feel brave, try to put it into live setups
+
+
+How does this plan sound ?
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1