On 02/15/2013 3:31 PM, "Jóhann B. Guðmundsson" wrote: > On 02/15/2013 01:50 PM, Honza Horak wrote: > > I still see the differences between MariaDB and MySQL to be very > > little. > > Difference never the less and difference in behavior ( which mariadbs > own benchmarking on their website proof ) which means every server > tweak > that has been done for the mysql host has to be redone to take > whatever > changes and features mariadb introduces. Can you be more specific, what tweaks you mean? > >>>> If you install mate or cinnamon or unity for that matter would > >>>> you > >>>> expect to be migrated and running Gnome 3.x after upgrade or > >>>> would you > >>>> expect to be continuing to use and run what got forked or based > >>>> of it. > >>> > >>> This is already too extreme, we cannot compare Gnome forks and > >>> MySQL > >>> forks. It's really a different scenario. > >> > >> Same fundamental rules apply as I see it just different ( fork ) > >> components. > > > > So what about upstart->systemd or Gnome2->Gnome3 switches? These > > also > > took place without users interaction and it was not without > > problems. > > OK, they aren't forks, just new features. Why not take MariaDB just > > as > > a new feature? > > upstart was never properly integrated into the distribution so it's > more > accurate to talk about sys V --> Systemd and my advice to any > distribution that thinks of making that switch to do so within one > release cycle and arguably systemd should never have had that > backward > compatibility ( to that certain extent it has ) to sys V > implemented. > > Doing so has caused users to expect sysv/upstart like behavior of the > init systemd as opposed to approach and embrace it as new technology. > > That said neither systemd nor Gnome 3 are forks however mariadb is so > it > will ( as is the nature of all forks ) grow further away from it's > origin in time ( how fast that happens depends on it's maintainers ), > thus it should be treated as fork and a completely separated database > product that is *based* on mysql and packaged as such It's possible, but I see that as another reason to do the switch to mariadb now, than later. > > Well, in case we wouldn't obsolete mysql -- then either we could do > > it > > in F20 and have the same problem a few months later > > Sorry not following as long as someone is willing to maintain mysql > in > the distribution we should not be dealing with any kind of potential > replacement migration. The reason of replacement is not that nobody is willing to package mysql. The reasons were stated on the feature page: https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB > > or don't do it at all and then we would have troubles with CVE and > > unfriendly upstream forever. > > > > Still not following I would assume the more these two components grow > apart the more CVE troubles we have and which unfriendly upstream > mysql > or mariadb one? MySQL one ;) The problem is not number of CVE, but the information about them -- again, more info on the feature page and it shouldn't be hard to find Oracle's announcements about making these and other info (e.g. tests) private. Honza -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
