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

Mon Jan 25 22:14:01 UTC 2016

In this summary I make no new arguments. I only summarise what has
already been said and provide references to back up what has already
been said. References are in the form [YYYY-MM-DD] or [YYYY-MM-DD-X]
where disambiguation is needed. URLs are at the bottom.

Where I have not used quotes, I am paraphrasing for brevity. Where I
state "no response", rather than lack of any response on any topic from
the team mentioned, I mean that there has not been a reply to the
particular point I am summarising.

I will send a separate email about what I propose we do next. In this
email, I'm sticking to the historical record of facts already raised so
that we can all refer to it.

Since there are many different hats involved in the discussion and they
are all quite wordy to disambiguate, I use the following abbreviations:

MySQL: MySQL(TM), Oracle's product
MariaDB: MariaDB(TM), MariaDB Corporation's product that is derived from
	MySQL
R: Debian (R)elease team
S: Debian (S)ecurity team
M: Debian MySQL (M)aintainers team, when speaking unanimously for both
	MySQL and MariaDB packaging (both are packaged within the same
	team)
M[MySQL]: Debian MySQL (M)aintainers team, the subset backing MySQL
M[MariaDB]: Debian MySQL (M)aintainers team, the subset backing MariaDB
U[MySQL]: (U)pstream for MySQL

As you know, some of the same people wear more than one of the hats
above. In this summary I attribute the hat, not the person.

* Background

M want to maintain both MySQL and MariaDB in testing and to release in
stretch. R and S expected M to remove one or the other, but every time
it came up [2014-10-01-A][2015-07-23-A], M immediately confirmed that it
intends to continue maintaining both
[2014-10-01-B][2015-07-23-B][2015-07-23-C]. Since the default position
is for all packages in unstable to migrate to testing, M assumed that
the status quo would remain unless R sought to change it. R has known
about the situation since [2014-10-01-B] but took no action.

However M eventually felt that the threat of removal was blocking
progress [2015-07-23-A][2015-09-08], so M asked R for a clear decision
on whether stretch will ship both MySQL and MariaDB or just one, and if
the latter then to decide on which one [2015-09-14].

These are the points of contention that have been identified by R and S,
which leads them to favour dropping MySQL:

1. "mysql isn't maintained in jessie"
2. "no disclosure of security issues w/ patches"
3. "we have two forks of the same codebase"
4. "point releases can contain anything"

When pushed by M[MySQL] [2015-12-16], neither R nor S have been able to
identify any other issues apart from the ones on this list. Nor have R
or S identified any new issues since that meeting having had time to
reflect.

In my opinion, there is a common theme here. Since the second IRC
meeting [2015-09-23], R and S repeatedly refuse to expand on some of
these problems so that M[MySQL] might fix them. Instead they
continuously tell us that this has been discussed before and that they
won't enter into it again [2015-12-16][2016-01-11-A][2016-01-14]. But
M[MySQL] are unaware of R or S ever having expanded on these issues.
Every time R and S claim reference to previous discussions, M[MySQL]
asks for references so that they can read up on these claimed previous
discussions, but neither R nor S have never been able to provide any.
Despite M[MySQL] pointing this out [2016-01-15-A], R and S still refuse
to expand on these problems [2016-01-14].

Next I'll summarise discussion separately on each of these four points
of contention.

* 1. "mysql isn't maintained in jessie"

R: [2015-09-23] Please maintain MySQL better in jessie and squeeze.
M[MySQL]: OK.
R: [2015-12-16] "mysql isn't maintained in jessie"
M[MySQL]: [2016-01-07] Yes it is; we have been diligent since you asked
	us in [2015-09-23] [evidence provided].
R: [no response since 2016-01-07]
S: No it's not; we did it because you didn't copy in the bug.
M[MySQL]: [2016-01-11-B] But there has only been one update since you
	first brought this up. In that update we did notify the bug
	[evidence provided], but you missed that and uploaded anyway. So
	we are being diligent, even if you did trump us.
S: [no response since 2016-01-11]

Following this exchange, I think S and M[MySQL] are working well
together in the handling of the subsequent security announcements (5.5
and 5.6) [2016-01-18-A][2016-01-18-B].

Thus I consider this issue resolved, unless R or S say otherwise and
can explain why.

* 2. "no disclosure of security issues w/ patches"

R: [2015-09-16-A] States that a significant reason to ship only one
	variant comes from S.
M[MySQL] and U[MySQL]: [2015-09-16-B] Asks for S' reasoning.
[2015-09-23] (IRC meeting)
R (speaking for S): "the security team have doubts about
	mysql upstream security processes; maria is less of a problem";
	"the security team's complain is that they're doing all the work
	for security releases when they are required".
M[MySQL]: We can take that on, and can talk to the security team about
	required disclosures.
R: [2015-09-23] [takes action to coordinate with the security team, but
	never does so]
U[MySQL]: [2015-12-23] Please explain exactly what you need and I'll
	start a discussion internally to fix it.
M[MySQL]: [2016-01-07] Please explain exactly what is missing.
S: [2016-01-14] "Information about specific security issues and their
	mapping to fixes...need to be publicly available". "This is EOD
	from my side. This has all been discussed to death and I won't
	spend further time on this."
U[MySQL]: [2016-01-15-B] We want to examine whether we can fulfil
	Debian's needs under our existing disclosure policies, or get
	our disclosure policy changed to meet Debian's needs. To do this
	we need to understand exactly what you need. Please tell us. "If
	a public announcement linking CVEs and patches is an absolute
	requirement, is this the only requirement? ... I can't go back
	and ask for more if a new requirement suddenly pops up, so I'll
	need the complete list of requirements first. The Debian MySQL
	team has asked for a list, in writing, several times now, but
	that list has not been produced."
R/S: [no response]

On [2015-12-28], M[MariaDB] asked U[MySQL] for information on some CVEs
affecting MySQL that might also affect MariaDB. U[MySQL] did not know
[2016-01-11-C]. S claimed that this is a reason to drop MySQL from
Debian [2016-01-11-D]. In [2016-01-11-E], M[MySQL] responded that it is
not reasonable for U[MySQL] to answer questions about MySQL derivatives:
that it is only reasonable for U[MySQL] to be expected to answer
questions framed in terms of its own product. M[MySQL] requested that S
explain exactly what information is required from U[MySQL], framed in
terms of MySQL. M[MySQL] also pointed out that missing information about
MySQL means that there is missing information about MariaDB in this
case, and so there is no technical reason here to reject one variant
over the other. No response from S since 2016-01-15.

So far the only input that U[MySQL] have received on this matter is "no
disclosure of security issues w/ patches" and "Information about
specific security issues and their mapping to fixes...need to be
publicly available". This is the full extent of the detail of the
problem that has been provided by R or S.

I consider this issue still open. It is blocked on S to tell U[MySQL]
details on exactly what U[MySQL] need to provide (eg. what they mean by
"information") so that U[MySQL] can check if they can disclose it under
their existing policies or understand what exception to seek internally
so that they can disclose it. It is not reasonable for S to expect
U[MySQL] to change their policy in order to meet a goal if S refuse to
tell U[MySQL] how success against that goal will be measured.

* 3. "we have two forks of the same codebase"

M[MySQL]: [2016-01-07] not actionable by its nature. But why wasn't this
	issue raised when MariaDB was accepted into Debian? Why is MySQL
	vs. MariaDB an exception [examples of other seemingly acceptable
	forks]?
R: [no response since 2016-01-07]

I consider this issue closed. It isn't really an issue that anyone can
address; more of a statement of fact that doesn't swing the balance
between MySQL and MariaDB in any particular direction.

* 4. "point releases can contain anything"

M[MySQL]: [2016-01-07] Postgres and MariaDB do this at least as much as
	MySQL [evidence provided]. Why is this a problem with MySQL and
	not the others?
R: [no response since 2016-01-07]
U[MySQL]: [2016-01-07] When we consider whether to commit a proposed fix
	to a point release branch, we consider how this will affect
	Linux distros. We are more than happy to discuss what changes
	are and are not acceptable.
R: [no response since 2016-01-07]

I consider this issue closed. MySQL is doing the same as other upstreams
that Debian accepts, including MariaDB, so there is no reason that this
swings the balance between MySQL and MariaDB in any particular
direction. Moreover, U[MySQL] have said that they're willing to discuss
R's needs to influence what they put in a point release
[2015-09-23][2016-01-07]. It's just up to R to raise any changes if
required. Thus, rather than "anything", what goes into a point release
is currently "what R wants", if only they would tell us.

* Summary of options and selection status

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.

M wants 1. R and S appear to have proposed 2b on the basis of the four
points of contention summarised above. Following discussion I think all
of these points have become moot, for the following reasons (again, I'm
just summarising the arguments that have already been made):

1. "mysql isn't maintained in jessie": M[MySQL] have reacted to R's and
S' concerns and it is now maintained. There is no longer any reason to
reject MySQL in favour of MariaDB on this basis.

2. "no disclosure of security issues w/ patches": this applies equally
to MySQL and MariaDB as the [2015-12-28] thread shows. U[MySQL] are
additionally blocked on S to consider making any change to U[MySQL]
disclosure policy. Whether we drop MySQL or MariaDB from testing, the
security situation for the remaining variant in Debian remains the same.
So there is no reason to reject MySQL over MariaDB on this basis.

3. "we have two forks of the same codebase": doesn't help pick one over
the other. So there is no reason to reject MySQL in favour of MariaDB on
this basis.

4. "point releases can contain anything": applies equally to MySQL and
MariaDB [2016-01-07]. So there is no reason to reject MySQL in favour of
MariaDB on this basis.

One final point, made in [2016-01-11-E]: if S would actually engage
U[MySQL] productively, as U[MySQL] have offered, then we could fix the
security situation in Debian for both MySQL and MariaDB at once.

* References

[2014-10-01-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-October/007114.html
[2014-10-01-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-October/007115.html
[2015-07-23-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008020.html
[2015-07-23-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008021.html
[2015-07-23-C] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008026.html
[2015-09-08] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008151.html
[2015-09-14] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008162.html
[2015-09-16-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008183.html
[2015-09-16-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-September/008196.html
[2015-09-23] http://meetbot.debian.net/debian-release/2015/debian-release.2015-09-23-17.59.log.html
[2015-12-16] http://meetbot.debian.net/debian-release/2015/debian-release.2015-12-16-19.22.log.html
[2015-12-28] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-December/008499.html
[2016-01-07] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008522.html
[2016-01-11-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008536.html
[2016-01-11-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008540.html
[2016-01-11-C] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008533.html
[2016-01-11-D] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008536.html
[2016-01-11-E] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008539.html
[2016-01-14] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008549.html
[2016-01-15-A] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008555.html
[2016-01-15-B] http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008557.html
[2016-01-18-A] Thread starting at http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008569.html
[2016-01-18-B] Thread starting at http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008571.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20160125/e91fea17/attachment.sig>