Hello! As the principal maintainer of MariaDB server packaging in Debian I should probably also chip in here.
First of all I'd like to thank Robie for the summary. Robie is correct in pointing out that the release and security team's arguments are somewhat based on disgust for Oracle and less on technical merits of MySQL packages in Debian. It is not very nice of Oracle to keep the CVE details hidden even to the extent that they don't give out the details on a pkg-mysql-maint mailing list when asked, not even when the questions were regarding several months old CVEs that Oracle has had fixed in their releases for some time, and disclosure could not generate much harm anymore. Not nice indeed, but however not against the Debian policy, as commenters in this thread rightfully point out. Has any other project ever been kicked out from Debian due to too much security by obscurity? Oracle also has other things freedom and openness loving debianists don't like, for example non-public bug tracker, non-public source code development repository, no external committers, all development discussions are done in in-house meetings and outside participation via mailing lists or irc is practically impossible, online documentation is no longer available on a free license, even man pages have been removed from project source code etc. MariaDB is a much nicer choice in this regard. Oracle MySQL basically does code dumping instead of real free and open source software. But so does many other companies too and their software is included in Debian. DFSG does not forbid the code dumping style as long as the code dump is actually released using a real free/open license. Also the comparisons to OpenOffice vs LibreOffice, Hudson vs Jenkins etc are not fair. For Oracle the MySQL project has a special role and they keep developing it, so it is not a good argument to bluntly punish Oracle MySQL for mismanagement in other projects. The release and security teams should present, as Robie points out, concrete and actionable lists on things that are wrong, and the "wrongness" should preferably be based on Debian policy or something else predictable and not on newly invented rules. Presenting ethical arguments is OK if they are based on Debian core documents. I am of course not against using ethics in the decision making process, but the people who put a lot of time and effort in MySQL packaging in Debian need fair treatment, and more objective technical arguments are therefore preferred. Presenting technical arguments should be based on a comparison of e.g. https://tracker.debian.org/pkg/mysql-5.5 https://tracker.debian.org/pkg/mysql-5.6 https://tracker.debian.org/pkg/mariadb-5.5 https://tracker.debian.org/pkg/mariadb-10.0 Examples of technical arguments I'd prefer to use instead of general disgust of Oracle arguments: - Quality: mysql-5.6 has 135 open bugs despite never being part of a Debian release and thus having exposure to the big Debian user masses. Some of them are even RC. The package mariadb-10.0 has only 10 bugs, which of 5 were filed by myself as TODO items with priority wishlist, and it actually ships in Jessie for big audience. - Quality: mysql-5.6 ships the same version number libmysqlclient.so.18 as 5.5 but the ABI is different and according to investigations by Robie Basak going back September 2014 [1] the upgrade might break something, and while it is now partially remedied, the ABI bump has never been done, the symbols file to track this all is missing from the packaging, and there is a Lintian override to keep Lintian quiet about the lack of a symbols file [2] - Quality: mysql-5.6 only runs ~600 tests as part of their Debian build, while MariaDB has 4000+ tests, making MySQL test coverage much smaller than the MariaDB one, thus catching less issues on many of the Debian platforms as Oracle MySQL probalby don't test those at all in-house. - Activity: Since the beginning of 2015 mysql-5.6 packaging master branch in Debian unstable has had 118 commits by 12 authors, while the mariadb-10.0 master branch in Debian has had in the same time 231 commits by 14 authors (authors don't include patch submissions and translators). I would claim MariaDB is more actively maintained. Note that uploads are done by Robie and me for mysql-5.6 and mariadb-10.0, who both are DMs. The team does not have any really active DDs at the moment, which is a problem for both packages. [1] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812812 [3] git log --since='2015-01-01' --oneline | wc -l [4] git log --since='2015-01-01' | grep Author | sort -u | cut -c -20 | sort -u | wc -l Then a few words about the decision: 2016-01-26 0:14 GMT+02:00 Robie Basak <robie.ba...@ubuntu.com>: > My original request for a decision proposed one of the following > options, which I think we all agree are the only options available: > > 1) We carry and ship both, which I believe is the preference of the > Debian MySQL Maintainers team by default since we do not agree to any > other option. We have representatives from both sides who are working > together and putting in the work to make this work technically. > > 2a) We carry both in unstable, but only MySQL in testing. > > 2b) We carry both in unstable, but only MariaDB in testing. > > 3a) We drop MariaDB completely, keeping only MySQL in unstable and > testing. > > 3b) We drop MySQL completely, keeping only MariaDB in unstable and > testing. The pkg-mysql-maint team stance so far has been option 1 and we've put a lot of effort in making it technically possible to be so. In particular Robie (paid by Canonical) put a lot of effort in de-coupling the configs and that worked out well. Ubuntu is likely to keep MySQL in their repos so having the situation identical in Debian makes life easier for me who needs to take care of the package in both distros. Option 3a would be very unfair to me and to all MariaDB packaging contributors. Option 3b would be quite radical and probably hurt a lot of users by introducing a quick forced migration. Although in SUSE and RedHat and derivatives they did option 3b and managed it, I think Debian with the universaliness motto should not jump to option 3b. If option 1 is not accepted, then option 2b would be the next best thing in my opinion. That would require that the file libmysqlclient.so.18 would start to be generated from the mariadb-10.0 sources. I am fine with that. I still hope the release and security team to consider option 1. It's quite OK. MySQL maintenance in Debian is good enough and Oracle will probably keep maintaining MySQL 5.6 for the term Debian Stretch is in production. If you want to see an increased shift towards MariaDB we could mass file bugs against packages that have "Depends: mysql-server | virtual-mysql-server" to switch to "Depends: mariadb-server | virtual-mysql-server" so that the "Debian default" would be MariaDB (in regards to the database service provider - this change would not affect the client library usage) and then give Debian users at least one stable release more time to use MySQL if they want, and then ultimately in some years allow us to check how users have "voted" in popcon results or something. As a final word: if you want to push Oracle towards better policies and have them invest more resources in raising Debian packagers and Debian policy followers, you will have more progress along that path if keeping the dialog open and not straight out kicking Oracle MySQL from Debian. And who knows, maybe having Oracle MySQL in Debian side-by-side with MariaDB can help keep up healthy competition and both of them evolve faster, leading to great benefits for all users? I vote the same as Robie: option 1, thanks! - Otto PS. Can somebody please remind me of what time and on what channel the meeting is tomorrow so that I can at least "listen" in on how the discussion goes?