19:22:58 <nthykier> #startmeeting
19:22:58 <MeetBot> Meeting started Wed Dec 16 19:22:58 2015 UTC.  The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:22:58 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:23:16 <nthykier> #addchair ivodd
19:23:21 <nthykier> #addchair pochu
19:23:25 <nthykier> #addchair jcristau
19:23:47 <nthykier> #topic MySQL and MariaDB
19:25:17 <nthykier> Ok - starting with the MySQL and MariaDB.
19:25:26 <nthykier> rbasak: are you around as well? :)
19:25:29 <rbasak> Yes
19:26:38 <jcristau> morning.
19:27:35 <pochu> so from my POV we're shipping two forks of a security sensitive software. so we should pick one and get rid of the other
19:28:06 <pochu> add to that that the security team is not happy with one of them as nobody from its team is helping with security updates, and there is no information disclosed about the security holes
19:28:29 <pochu> is that a good summary? or do people disagree?
19:28:38 <jcristau> +1 here
19:28:54 <ivodd> +1
19:29:15 <nthykier> I believe there was some interest from MySQL to improve the situation but I have not heard of the results of said efforts
19:29:28 <nthykier> beyond that +1
19:29:29 <rbasak> Are you interested in my take on this? I'm conscious that this is your decision to make, at this stage at least.
19:29:56 <jcristau> is there anything new?
19:29:56 <pochu> nthykier: we got a mail from $security, saying there had been no approach after the previous meeting (the one 2 or 3 months ago, so there's been enough time...)
19:30:47 <pochu> see Message-ID: <20151027220438.GA5243@pisco.westfalen.local>
19:31:25 <pochu> rbasak: sure, go ahead
19:31:48 <rbasak> I wasn't aware that the buck was with Oracle. I don't think they knew, either, as I've been with regular contact with them on this. Does anyone have the previous IRC meeting log URL to hand?
19:32:13 <nthykier> http://meetbot.debian.net/debian-release/2015/debian-release.2015-09-23-17.59.html
19:32:18 <rbasak> Am I right in thinking that Debian has never had to choose between two forks before at release team level? To my knowledge, maintainers have always made the choice.
19:32:21 <rbasak> Thanks
19:33:10 <rbasak> The forks seem to be diverging rapidly. And Debian do historically allow multiple upstreams that achieve the same goal, for example MTAs. So the crux of this is really a decision based on the fact that they are forks.
19:33:22 <pochu> there was ffmpeg vs libav for Jessie, for example
19:33:31 <jcristau> rbasak: and based on the fact that oracle.
19:33:36 <rbasak> I thought that was concluded by the maintainers involved?
19:33:48 <pochu> we blocked one from entering testing
19:33:51 <rbasak> I think Oracle should only be judged here on their behaviour with this project.
19:33:55 <rbasak> Ah, I see. OK.
19:34:31 <jcristau> afaict their behaviour with this project is fairly close to their behaviour in general.
19:34:32 <nthykier> rbasak: The RT decided there should be only one implementation (also happened with libjpeg vs. libjpeg-turbo, though the actual choice was deferred to the ctte)
19:35:15 <ivodd> is there any indication that Oracle changed their behaviour since last meeting?
19:35:17 <rbasak> From the forks perspective, it seems odd to me that code history matters, rather than the current releases.
19:35:22 <ivodd> if not, there's probably not that much to discuss
19:35:37 <rbasak> ivodd: can you be specific? What behaviour do you think needs changing?
19:35:44 <rbasak> Their security announcement policy certainly has not changed.
19:35:50 <rbasak> But I'm not aware of any other unreasonable behaviour.
19:35:53 <ivodd> that's the main issue
19:36:03 <jcristau> rbasak: history of how software is maintained within debian is relevant
19:36:08 <nthykier> rbasak: Even if we accept that they are two different "distinct" projects, we are still at the point where the security team feels that the security support for MySQL is inadequate
19:36:21 <rbasak> OK, this is useful, thanks.
19:36:25 <rbasak> I was hoping to have a list.
19:36:42 <jcristau> and if the security team is left handling the security updates for mysql in stable, their input will be important.
19:37:06 <rbasak> I'm pretty sure that Oracle are happy to help with this kind of requirement.
19:37:18 <jcristau> i'm pretty sure they've had their chance
19:37:53 <ivodd> if there is no clear improvement now, there is no time to delay this discussion any longer
19:38:02 <ivodd> so I'm with jcristau here
19:38:19 <rbasak> From the last IRC Log
19:38:20 <rbasak> 19:08:49 <jmw> #action jmw will try to get the security team and pkg-mysql-maint talking about upstream relations
19:38:23 <rbasak> Did that happen?
19:38:26 <rbasak> I don't think Oracle heard anything.
19:38:31 <rbasak> Seems a bit unfair on them in that case.
19:41:04 <jcristau> i don't think that's accurate.  and i'm not sure being fair on oracle is what we should be aiming for anyway.
19:41:41 <mehdi> it is true that nothing seems to have been tried.
19:41:48 <nthykier> FTR, ryeng (from Orale) was at the last meeting
19:42:37 <jcristau> mehdi: there were multiple mails on pkg-mysql-maint pointing out the issues.
19:42:39 <nthykier> Oracle even
19:43:20 <mehdi> pkg-mysql-maint isn't upstream or ...?
19:43:35 <rbasak> jcristau: do you have links please?
19:43:46 <jcristau> no...
19:44:15 <jcristau> mehdi: it's not our place to deal with upstream.  that's what the package maintainers are for.
19:44:16 <rbasak> I'm not aware of much recent communication on this.
19:44:55 <mehdi> if have a message from an Oracle representative that says"our security processes suck and will not change" will greatly help
19:45:00 <rbasak> I think that if you have specific concerns and are using them to guide your decisions, then you need to enumerate those concerns exactly.
19:45:01 <jcristau> rbasak: as far as i'm concerned that means nothing has changed
19:45:24 <jcristau> sigh.
19:45:27 <rbasak> Right now it's a vague "security don't like it" rather than any actionable items from my perspective.
19:45:32 <jcristau> they're not new concerns.
19:46:02 <rbasak> The one concern I understand is the lack of specific patches or commits associated with CVEs, and perhaps their schedule.
19:46:11 <rbasak> Is there anything else?
19:46:20 <jcristau> the package is not maintained adequately in jessie today, and there's no sign it's getting better
19:46:41 <rbasak> Maybe you could either point to an ML archive URL with a specific list, or reply to my email with a specific list please?
19:46:42 <pochu> maintainers not doing security updates
19:46:53 <rbasak> OK, that's useful, thanks. Anything else?
19:47:05 <jcristau> we're going round in circles
19:47:22 <pochu> yes
19:47:27 <pochu> this goes back to July
19:47:30 <pochu> I'm not delaying it any longer
19:47:38 <mehdi> jcristau: but then again, mysql is not the only package badly maintained in jessie, security wise
19:47:51 <jcristau> mehdi: it's one where there's an alternative
19:47:52 <pochu> mehdi: but we have mariadb
19:48:31 <mehdi> iiuc, the point is that the two solutions are diverging
19:48:56 <mehdi> so considering mariadb as an alternative is not accurate (to say the least)
19:48:57 <rbasak> I understand the feature set of MySQL 5.7 to be quite different from the latest MariaDB now. I don't follow the details though.
19:50:21 <rbasak> I suggest that you aren't being reasonable today given that your team's own action wasn't carried out from the previous IRC meeting and you are using the lack of movement as a result of that to make a decision now.
19:50:24 <nthykier> mehdi: Back to the point that even if they are diverging, the security team feels they cannot support MySQL and that the maintainers are not doing it
19:50:48 <jcristau> mehdi: surely it's an alternative as far as users of mysql 5.5 are concerned though?
19:50:56 <jcristau> and 5.5 is what we ship today
19:51:37 <rbasak> I'd like to have seen the result of that communication that didn't happen result in a list of actionable items for pkg-mysql-maint, and for the state of MySQL packaging to be judged on the outcome from that after the requirements have actually been enumerated.
19:51:42 <mehdi> so are we only concerned about jessie or also about stretch?
19:51:47 <mehdi> (today)
19:51:54 <jcristau> sigh
19:52:13 <pochu> mehdi: we're talking about stretch here
19:52:22 <mehdi> right, so not about 5.5
19:52:58 <mehdi> very nice behavior
19:54:20 <mehdi> pochu: can we delay the decision to next meeting and i take the action to talk with relevant people?
19:54:46 <mehdi> otherwise, i feel (but icbw) that we are about to make a decision based on poor arguments
19:56:01 <nthykier> To be honest, I very much doubt the outcome will change, though I can certainly appreciate your concern
19:56:10 <pochu> mysql-5.5  | 5.5.44-0+deb8u1 | stable                           | source
19:56:11 <pochu> mysql-5.5  | 5.5.44-0+deb8u1 | unstable                         | source
19:56:19 <pochu> Changes in MySQL 5.5.47 (2015-12-07)
19:56:20 <pochu> Changes in MySQL 5.5.46 (2015-09-30)
19:56:20 <pochu> Changes in MySQL 5.5.45 (2015-07-24)
19:56:20 <pochu> Changes in MySQL 5.5.44 (2015-05-29)
19:57:15 <pochu> that doesn't seem well maintained
19:57:24 <pochu> mehdi: I'm basing it on the feedback we got from the security team
19:57:33 <mehdi> Well, as much as chromium.. but there are certainly other examples.
19:58:01 <pochu> we're not shipping two chromium forks...
19:58:19 <mehdi> point.
19:58:53 <rbasak> That's specific and actionable, thanks. I will relay that to Oracle and see what commitment (and action) they can take on that.
19:59:17 <rbasak> To be clear, is your concern security, non-security or both?
19:59:41 <mehdi> pochu: also, about testing, 5.6 is the target (or even 5.7 when ready), not 5.5
19:59:44 <rbasak> Obviously more is better, but what's the crucial thing here? Outstanding CVEs, or just not the latest upstream point release?
20:00:55 <nthykier> mehdi: I am almost certain that 5.5.4[567] includes security updates
20:01:06 <nthykier> (which I presume was pochu's argument)
20:01:20 <rbasak> I see CVEs fixed in 5.5.46.
20:01:51 <mehdi> with this kind of software, each new day is made of new CVEs :)
20:01:56 <mehdi> so yeah, no doubt about that
20:02:01 <rbasak> Not sure about 47. It may be that they just haven't been made public yet.
20:02:36 <Corsac> I don't think the point is that point releases contains security fixes
20:02:48 <Corsac> the point is actually more the opposite
20:03:17 <nthykier> no cherry-pickable patches? :)
20:03:21 <rbasak> Anyway, it can be fixed, if that is what the issue is. I just need to actually ask Oracle to help with that specifically.
20:03:57 <rbasak> If they don't, then you can say that it's not well-maintained.
20:04:15 <rbasak> But I think it's only fair to actually give them the opportunity first.
20:04:18 <Corsac> nthykier: that and/or the fact that those point release can contain anything actually
20:05:05 <Corsac> rbasak: I'm not much involved in MySQL, security wise, but I had the impression that enough shouting had been done about this Oracle policy
20:05:13 <Corsac> and if they wanted to change it, they'd have done it long ago
20:05:39 <rbasak> Corsac: that is true, although Oracle have had a good track record communicating with us on the Ubuntu side on changes that might be invasive. I can find links if needed. I know Ubuntu isn't Debian but I hope that shows that they are prepared to do it - we just need to open that communication channel.
20:05:55 <rbasak> (for Debian)
20:06:27 <rbasak> I'm not going to defend Oracle's policy (and I don't work for Oracle anyway).
20:06:45 <Corsac> then maybe pkg-mysql people should do that? (sorry I don't have the previous decisions so maybe it has already been proposed)
20:06:48 <rbasak> If that's the justification you give for a decision, then at least that's a specific reason.
20:07:00 <pochu> mehdi: if they don't do a good job of maintaining mysql in Jessie, they won't do a good job of maintaining it for Stretch
20:07:09 <mehdi> rbasak: while you are here, what is the status of 5.5 in Debian? Since there are also concerns on its maintainability in stable and sid.
20:07:10 <Corsac> rbasak: note: I'm not release team, I'm security team (and again, not much involved in MySQL)
20:07:11 <pochu> so I don't care if Jessie has 5.5 and Stretch would have 5.7
20:07:11 <rbasak> I'd like to understand all the reasons so we can communicate that effectively and give Oracle a chance to address them all.
20:07:36 <mehdi> pochu: because not the same people? like rbasak seems to be maintaining 5.6 but not 5.5
20:08:12 <pochu> then maybe he should care about Jessie...
20:08:15 <rbasak> mehdi: IMHO, the packaging for 5.5 is terrible, but we don't want to mess with that now it's in a release. I prefer to think long term which is why I've been working in 5.6 (and in 5.7 hopefully) to fix it all properly.
20:08:28 <mehdi> pochu: indeed. that's why i'm asking rbasak ;)
20:08:57 <pochu> I don't think poking Oracle people would change anything
20:09:19 <rbasak> pochu: I don't think it's reasonable to be making assumptions like that.
20:09:20 <mehdi> rbasak: concerns are twofold: 1) security support (potentially big releases with invasive changes); and 2) maintainers on Debian side.
20:09:32 <rbasak> pochu: tell them exactly what you want, and if you don't get it, _then_ you have a reason.
20:09:37 <pochu> in any case we can decide to drop mysql from Stretch, and revisit that in 3 or 6 months if necessary
20:09:48 <pochu> rbasak: *sigh*
20:09:56 <pochu> this has been in pkg-mysql-maint for months
20:10:03 <rbasak> pochu: where?
20:10:21 <rbasak> pochu: I don't believe I've seen a single specific enumerated list.
20:10:41 <pochu> see e.g. https://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-July/008020.html
20:10:49 <pochu> you could hav easked for a list, back then
20:10:54 <pochu> s/you/oracle/, if you want
20:10:56 <pochu> I don't care
20:11:09 <pochu> it is your obligation as a maintainer to maintain your stuff
20:11:24 <rbasak> Wait. What?
20:11:29 <pochu> we don't have to chase you for months to take care of things properly
20:11:32 <rbasak> As in my reply, we never agreed.
20:11:35 <rbasak> I responded.
20:11:54 <rbasak> That's exactly why I'm here.
20:12:04 <pochu> alright. we're going in circles
20:12:05 <rbasak> Because you keep threatening that without justfication because you aren't giving us a list.
20:12:24 <pochu> want a list?
20:12:33 <rbasak> Yes. An ML reply would be best.
20:12:37 <pochu> 1- mysql isn't maintained in jessie
20:12:56 <pochu> 2- no disclosure of security issues w/ patches
20:13:12 <nthykier> (cherry-pickable/isolated patches)
20:13:13 <pochu> 3- we have two forks of the same codebase
20:13:39 <rbasak> OK. Anything else?
20:13:39 <pochu> 4- point releases can contain anything
20:13:46 <rbasak> Sorry. Let me know when you're done please.
20:14:35 <pochu> I'm sure there are more, though I can't think of anything else right now
20:14:45 <rbasak> OK, let's go with that for now.
20:15:04 <rbasak> I'll relay that to the list. If you think of more later, please reply to my email to add them.
20:15:34 <rbasak> Now, if 1, 2 and 4 are resolved, then will you permit both MariaDB and MySQL in testing?
20:15:45 <mehdi> pochu: can you record that list with proper #item and #action plz?
20:16:25 <pochu> rbasak: I can't promise that
20:16:49 <rbasak> In principle?
20:16:54 <nthykier> Rather, if they are not resolved, MySQL will probably be replaced by MariaDB
20:17:02 <pochu> but I'd say if they don't happen, then one of the forks (mysql) would have to be removed
20:17:10 <pochu> exactly
20:17:11 <rbasak> I ask because if in principle the answer is no and you will pick MariaDB, then doing the others is pointless.
20:17:32 <rbasak> So it would be useful to know now, before taking on that work.
20:17:41 <pochu> surely at least maintaining mysql in Jessie isn't pointless :-)
20:18:55 <pochu> also fixing 2 and/or 4 helps reducing the risk of regresions
20:19:14 <nthykier> rbasak: How long do you think it would take you to get those resolved with Oracle?
20:19:33 <rbasak> I think they're all about to finish for Christmas if they haven't already.
20:20:06 <rbasak> I also don't think I can speak for them on this.
20:20:25 <rbasak> How about you set a deadline for at least an initial response from Oracle?
20:20:54 <nthykier> To be honest, we cannot use an intial response to much really.
20:21:16 <rbasak> I would expect an initial response to at least specify the timeframe they want.
20:22:15 <rbasak> If you then pulled MySQL from testing I wouldn't object in principle.
20:22:32 <rbasak> (pulled from testing because of lack of response, that is)
20:27:00 <nthykier> rbasak: I have an alternative proposal that might take a bit of pressure and emotional weight off this decision
20:27:19 <rbasak> Sure, go ahead.
20:27:43 <nthykier> I suspect one of the reasons why people have major concerns with MySQL is that it also affects reverse dependencies (e.g. via the client libraries)
20:28:03 <nthykier> Which means if MySQL is unsupported, then so is basically anything with a MySQL connector (when using said connector)
20:28:12 <nthykier> (unsupported by Debian)
20:29:48 <nthykier> If we migrated to MariaDB for the client libs, we would have less risk in our end.  Hopefully, that will also make people less concerned with the negotiations with Oracle dragging out
20:30:25 <rbasak> I appreciate the suggestion.
20:30:55 <rbasak> We decided to ship just one set of libs, though we could switch. But we decided that on the basis that they are the same anyway.
20:31:10 <rbasak> So yes, they are interchangeable, but MySQL is the upstream for them.
20:31:33 <rbasak> Switch to MariaDB for the client libs and you're still getting any updates from Oracle anyway, only now through MariaDB being their downstream for them.
20:31:54 <rbasak> This is to the best of my knowledge, I may be wrong and I can go ask to clarify.
20:32:28 <nthykier> To my understanding (which is definitely at least second-hand), MariaDB provides isolated security fixes
20:33:27 <rbasak> Sure, but for the client libs? Has that actually ever happened? I don't know either, but to the best of my knowledge it's unlikely.
20:33:42 <rbasak> I can raise this with both MySQL and MariaDB sides and ask the question though.
20:34:16 <rbasak> I just wonder how many previous CVEs even applied to the client libs.
20:35:07 <rbasak> If I could get Oracle to commit to providing timely updates to stable at least as quickly as otto does for MariaDB, this wouldn't be needed though, right?
20:35:37 <rbasak> I think that's a much easier ask than having Oracle change their security policy, for example.
20:36:27 <rbasak> Anyway, we've been talking long enough. Can we wrap up?
20:36:30 <pochu> the question still stands - do we want the two forks in Stretch?
20:36:36 <rbasak> Ah yes.
20:36:39 <pochu> (and we'll have to think about it and make a decision)
20:36:49 <pochu> your opinion on that would be welcome
20:37:18 <rbasak> IMHO, forks need to cease to be considered forks when they have diverged sufficiently enough. There must come a point when all will consider them to be separate.
20:38:21 <rbasak> Otherwise you'd be throwing out one of exim, sendmail, postfix, etc if one happened to get to where it is by making small changes to one of the others, on the basis that makes it a fork, and I don't think that makes any sense.
20:38:44 <rbasak> Now whether MySQL and MariaDB have diverged enough to consider them separate is another much more subjective matter.
20:39:02 <nthykier> To me it does not matter if the are forks or not, if one of them are not supported security-wise in Debian
20:39:09 <nthykier> anyway, actions
20:39:27 <rbasak> Well, that's fine.
20:39:35 <nthykier> rbasak: were you willing to do the communication with Oracle and tell them of the concerns?
20:39:38 <rbasak> And I agree with that perspective.
20:39:42 <rbasak> Yes, I'll take that action.
20:40:14 <nthykier> #action rbasak to talk to Oracle about the concerns of Debian
20:40:21 <rbasak> I'm basically saying that "they're forks" isn't a reason. But "Individual CVEs need to be dealt with twice, doubling the work" could be a valid reason, as well as "one isn't maintained well enough".
20:40:44 <nthykier> That latter is one of the Security Team's favorite arguments btw
20:40:48 <rbasak> But those things can be addressed, and I'm fine with a decision to kick one variant out if volunteers aren't found.
20:41:01 <rbasak> I just want to give Oracle a valid opportunity to volunteer after spelling it out for them.
20:41:24 <pochu> rbasak: please Cc debian-release@ on those discussions
20:41:27 <rbasak> ack
20:42:00 <nthykier> Dealine for responding to this "opportunity": One month - i.e the 16th of Jan?
20:42:10 <pochu> nthykier: sgtm
20:42:21 <rbasak> Can I stretch that a little please? It's effectively two weeks for employees since we're all generally off now.
20:42:26 <rbasak> I finish on Friday, for example.
20:42:35 <rbasak> How about 1 Feb?
20:42:46 <nthykier> That would mean two meetings away
20:43:38 <rbasak> How about 1 Feb and you remove mysql-5.6 from testing?
20:43:45 <rbasak> Any discussion needs to happen before then.
20:44:13 <rbasak> Uh.
20:44:22 <rbasak> A slight technical hitch with that comes to mind.
20:44:29 <rbasak> mysql-common is still part of src:mysql-5.6
20:44:44 <rbasak> I'm fine in principle with splitting that out.
20:44:46 <nthykier> plus anything depending solely on mysql would go as well
20:45:07 <rbasak> But I can't commit to getting that done immediately.
20:45:31 * nthykier just checked apt-cache rdepends <pkg>-server with pkg being mysql-5.5, mysql-5.6 and mariadb-server
20:45:52 <nthykier> eh, missing some -server in that list
20:46:02 <mehdi> and transitive closure?
20:46:07 <pochu> rbasak: that's why we need to make a decision soon. if we decide to kill one of them, we need time for a migration
20:46:33 <rbasak> OK, that's reasonable.
20:46:42 <rbasak> Call it 16 Jan then, and we'll see what Oracle can respond with in that time.
20:47:00 <pochu> ack, thanks
20:47:03 <rbasak> I doubt they'll be able to respond to the security disclosure policy question. But they may be able to commit to maintaining stable.
20:47:04 <mehdi> Looks like a deal.
20:47:50 <mehdi> nthykier: #info for the deadline?
20:48:01 <nthykier> #info Deadline for response from Oracle: Jan 16th 2016
20:48:20 <nthykier> Was trying, dealing with some horrible lack :P
20:48:35 <mehdi> fair enough :)
20:48:48 <rbasak> Thank you for the meeting everyone.
20:48:55 <rbasak> I feel that we have actionable things now, and I appreciate that.
20:49:19 <nthykier> You are welcome :)
20:49:37 <mehdi> Thank you for your contribution as well!
20:50:00 <rbasak> No problem.
20:50:41 <mehdi> next? (if any)
20:50:44 <nthykier> Any final words on this topic?
20:51:59 <nthykier> Nope, seems not
20:52:15 <nthykier> Ok - closing
20:52:18 <nthykier> #endmeeting