[debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB

Tue Jan 26 22:45:59 UTC 2016

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.basak at 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?