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
Attachment:
signature.asc
Description: Digital signature