18:59:41 <nthykier> #startmeeting
18:59:41 <MeetBot> Meeting started Wed Jan 27 18:59:41 2016 UTC.  The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:41 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:48 <nthykier> #addchair jmw
18:59:49 <jmw> indeed
18:59:54 <nthykier> #addchair KiBi
18:59:57 <nthykier> #addchair KiBiadsb
19:00:03 <nthykier> #addchair adsb
19:00:10 <nthykier> #addchair jcristau
19:00:11 <jmw> right let's rattle through the formalities:
19:00:14 <jmw> #topic Apologies
19:00:23 <jmw> I'm aware of at least pochu who will not make it, are there any others?
19:00:37 <nthykier> adsb: wasn't sure
19:00:48 <nthykier> sorry - adsb said he was not sure
19:00:54 <jmw> yes, he might catch us up
19:01:07 <nthykier> mehdi: ping?
19:01:47 <jmw> I should state delayed apologies for myself for last time (I did mail team), and also thanks for taking care of it that time
19:01:56 <jmw> s/and/but/
19:02:08 <nthykier> :)
19:02:17 <jmw> nthykier: looks like it might just be you and I then...
19:02:30 <jmw> oh well
19:02:45 <jmw> #topic Transitions
19:03:00 <jmw> as usual, pochu does a fabulous job managing transitions
19:03:19 <jmw> there is quite a lot of unannounced ones though, which are usually quite small but sometimes get tangled
19:03:26 <jmw> is that a problem we should deal with or is the status quo ok for now?
19:03:56 <nthykier> I have not heard of any considerable problems, so I presume it is ok for now
19:04:06 <nthykier> (though I have not looked at it)
19:04:18 <jmw> I have had a vague eye open, and it seems not to be too bad
19:04:30 <jmw> getting maintainers to move the transition on is sometimes more of an issue
19:04:55 <jmw> #info maintainer-led transitions seem to be working ok for the time being
19:05:08 <jmw> maybe we should remind library maintainers of their responsibilities in some bits?
19:05:22 <nthykier> That might be good :)
19:05:23 <jmw> I know how you love bits :)
19:05:38 <jmw> #agreed remind library maintainers of their responsibilities in next bits
19:06:10 <jmw> #topic g++5 progress
19:06:15 <jmw> aha this one has been brewing a while
19:06:40 <jmw> so this kindof ground to a halt at 47%, although I don't know how reliable that figure is for actual progress
19:06:54 <nthykier> it is useless
19:06:59 <jmw> right, that was easy then :)
19:06:59 <nthykier> (the figure)
19:07:27 <jmw> can you give an idea of where we really stand?
19:07:58 <nthykier> I suspect we have basically lost track of it because we did not handle progress loging correctly from the beginning
19:09:42 <jmw> #info the 47% completion label on the transition tracker is actually not very much use
19:09:44 <jcristau> rather because there's no way to handle progress logging
19:09:49 <nthykier> We should probably just get the last known items fixed (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-gcc@lists.debian.org;tag=libstdc%2b%2b-cxx11) and then close it at that
19:09:50 <jmw> ohai o/
19:10:31 <nthykier> There is - but it was manual and probably not structured well enough.
19:10:41 <jmw> that does look like a much more manageable list
19:11:04 <nthykier> I have an idea for "next time" (although I prefer there was no "next time" for this)
19:11:14 <jcristau> it might have been manageable if libstdc++6 shlibs had been bumped
19:11:18 <KiBi> (don't we have an upcoming gcc6? ;))
19:11:42 <jcristau> but it wasn't, so it isn't
19:12:54 <jmw> well, that list of bugs is something we can make some progress on probably, which is better than doing nothing
19:13:02 <jmw> pochu did ping some or all of them in october
19:13:40 <jcristau> the rc ones shouldn't affect testing anymore, hopefully?
19:13:43 <jmw> are nmus feasible? istr it was difficult to have confidence in uploads
19:13:48 <jcristau> so they can rot
19:13:59 <jmw> true
19:14:12 <jmw> maybe we should end the transition here then
19:14:30 <jmw> presumably there's been plenty of time for people to find breakage...
19:14:51 <nthykier> wfm
19:14:56 <jcristau> well, doko wanted the whole archive rebuilt with gcc5, transition or no
19:15:12 <jcristau> but that's not tractable, so i'd rather not have that on my plate
19:15:25 <jmw> #info rc bugs should no longer affect testing, so we will leave those out of the equation now
19:16:27 <jmw> I can't say I'm wild about rebuilding the whole archive
19:17:09 <nthykier> even then, you would probably need gcc-4.8 and gcc-4.9 removed first to ensure everything was built with gcc-5
19:18:05 <jcristau> jmw: libstdc++ rdeps rather than the whole archive, and most have probably already been rebuilt
19:18:12 <jmw> ack
19:18:27 <jmw> can we get away with just letting that one lie as well?
19:18:46 <jmw> you did say "whole archive" as well :P
19:18:56 <nthykier> wfm as well
19:19:30 <jcristau> should be possible with some projectb query to find the list of source packages that build a deb depending on libstdc++, figure out when it was last built and binNMU if it's before $cutoff
19:19:34 <jcristau> but, meh.
19:19:40 <jcristau> somebody who cares can do that
19:20:05 <jmw> I don't really mind either way, but as you say none of us particularly wants to do it, so
19:20:18 <jmw> #info rebuilding the archive is not very practical
19:20:37 <jmw> #info it's been long enough that any serious breakage should have become apparent by now
19:20:40 <jcristau> the little spare time i have is already not being spent on helping adsb manage the p-u requests queue, and i care more about that :(
19:21:14 <jmw> #agreed unless problems are found at this stage, we consider the g++5 transition over
19:21:22 <nthykier> Ack
19:21:24 <jmw> anything else to be said on this topic?
19:21:38 <nthykier> Not from me
19:21:59 <jmw> #topic MySQL variants in Stretch
19:22:21 <jmw> I assume we have representation from robie or otto and maybe others? I forget nicks, sorry
19:22:32 <ryeng> _o/
19:22:37 <nthykier> rbasak: otto_: ltangvald:
19:22:42 <ltangvald> Yup
19:22:51 <ltangvald> Though I probably won't say much
19:23:20 <jmw> for the record, I should apologise for having dropped the ball so badly on this in september; there are reasons, but I haven't shared them publicly
19:24:29 <nthykier> ok
19:24:43 <jmw> just trying to work out where to begin on this :)
19:25:08 <jmw> how did the recent DSAs go from the maintainers perspectives?
19:25:19 <rbasak> Thanks jmw. I appreciate that everyone involved has other things to do too, and I thank you all for the time that you have been able to commit.
19:25:27 <jmw> there were one each I think?
19:25:59 <rbasak> The security uploads are all done, as of a few hours ago. There were a few technical hiccups, so I think we have some points we can improve on for next time.
19:26:07 <otto_> o/
19:26:33 <rbasak> It's a little painful as the primary maintainers (of both MySQL and MariaDB) are not DDs, but hopefully that can be fixed in time.
19:27:26 <rbasak> (it's also painful because the builds take so long and don't work in parallel; that's better in testing already)
19:27:27 <jmw> there should be at least one DD very soon, so that will hopefully make things easier
19:27:40 <otto_> jmw: you are one of the DAMs right? I've been waiting in DAM review since November to become a DD.. wink, wink :)
19:27:49 <jmw> I just have to get round to finishing otto's review
19:28:07 <jmw> quite :)
19:29:16 <otto_> Robie is also excellent candidate, his work is always of high standards.
19:29:37 <jmw> ok, but that's not really what we need to get to here
19:29:51 <otto_> It is apitty database packaging is not very sexy and practically no now team members have appeared in a long time
19:29:58 <rbasak> Thanks otto_ :)
19:30:01 <otto_> s/apitty/a pity/
19:30:31 <rbasak> Though if MySQL is removed, that may become irrelevant. The only other package I maintain needs to be removed probably now (it's Mozilla Persona related)
19:33:39 <mehdi> nthykier: o/
19:34:50 <nthykier> On that note.  I have been told that the Security Team is drafting a policy on their requirements for upstream security policies
19:35:24 <nthykier> "Security Transparency" was the actual words used
19:35:42 <nthykier> #info Security team working on a "Security Transparancy" document
19:36:29 <jmw> I think that will go a long way towards expectation-setting
19:37:04 <rbasak> Thank you - I really appreciate that. I hope it will help with resolving the disclosure policy issue we have with both MySQL and MariaDB at the moment.
19:37:12 <nthykier> Though, I got no ETA on its completion nor its current status. Presumably it is in a very early state
19:37:45 <otto_> I don't think MariaDB has any disclosure problem. Take as example very recent CVE from MariaDB, mailed to oss-security
19:38:18 <nthykier> otto_: http://www.openwall.com/lists/oss-security/2016/01/26/3
19:38:21 <rbasak> otto_: MariaDB *upstream*, don't, but from a Debian perspective it does, right? Or else, why did you have to ask Oracle on the ML in relation to MariaDB?
19:38:22 <nthykier> ?
19:40:32 <nthykier> rbasak: Based on the security team's words and actions so far, I suspect they feel the same way as otto_ (although, it is my interpretation)
19:40:59 <rbasak> I understand that the root cause is Oracle's disclosure policy (which we hope to have them change).
19:41:16 <rbasak> But AFAICT, both the MariaDB and MySQL packages are impacted by this issue from Debian's perspective.
19:41:26 <rbasak> The security team themselves said so.
19:41:48 <rbasak> http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008536.html
19:41:51 <nthykier> rbasak: impacted yes, but there is a difference between being affected by MySQL and behaving like MySQL
19:42:21 <rbasak> Yes, that's true. So the question is: does Debian make a decision based on technical impact, or something deeper?
19:43:11 <jcristau> making a decision based on whose policies are reasonable and whose aren't wouldn't be the worst idea ever, imo
19:43:15 <rbasak> If deeper, then I'd question whether the release or security teams have the remit to make that decision (I don't know - I don't mean to accuse).
19:44:29 <jmw> that is an interesting constitutional question, but I don't know if that's a rabbit hole we want to go down too far
19:44:38 <rbasak> I'm not sure that makes sense though. I could release rbasakSQL tomorrow, and have amazing Debian-spirit-compliant policies.
19:44:51 <rbasak> Anyway, sure.
19:44:56 <rbasak> Let's move on.
19:46:12 <jmw> the disclosure/information sharing thing is very relevant though. I think (though I can't speak for them) that a large part of the security team's objection is the quality of information that arrives in disclosures (the ones like "unspecified vulnerability")
19:46:32 <jmw> Debian is historically very open about what is wrong and how it's being fixed, and those make that very hard
19:46:51 <jmw> I am aware that some work is being done in that area though
19:48:50 <rbasak> Yes - I look forward to seeing the outcome for that. I hope that it will fix the situation for both MySQL and MariaDB.
19:49:16 <jmw> who is liaising with oracle about that? I get confused easily
19:49:32 <nthykier> Is there anything new on the Oracle side?  My understanding was that they were waiting for a fully specified list of things to implement
19:49:52 <rbasak> jmw: ryeng is an Oracle employee. It's on the pkg-mysql-maint list.
19:50:02 <ryeng> nthykier: Yes, I'm waiting for the security team to come back with some requirements.
19:50:06 <rbasak> One might say I'm liasing I suppose, and I'm happy to do that. But ryeng is happy to participate directly.
19:50:21 <rbasak> He's on the list, I mean.
19:50:21 <nthykier> ltangvald is as well (based on the @oracle.com in from)
19:50:33 <SpamapS> o/
19:50:47 <ltangvald> Yeah. I work on our Debian/Ubuntu packaging
19:51:02 <rbasak> ltangvald is being delegated a ton of the engineering work. He's behind the new 5.7 branch (not uploaded yet) and prepared the security updates.
19:51:07 <jmw> ltangvald may not be directly involved in the disclosure discussion though?
19:51:19 <ltangvald> No
19:51:22 <ryeng> No, I'm handling that from the Oracle side.
19:51:22 <rbasak> jmw: right. That's ryeng really. We're leaving ltangvald out of the politics.
19:51:26 <jmw> ok, thanks
19:51:32 <jmw> let me try and summarise some infos:
19:51:34 <jcristau> lucky him
19:51:36 <jcristau> :)
19:51:38 <ltangvald> :)
19:51:40 <nthykier> heheeh
19:52:28 <nthykier> jmw: ok :)
19:52:31 <jmw> #info the security team is working on a policy for security disclosure requirements, but it's not yet clear quite what shape that will take
19:53:29 <jmw> #info ryeng is liaising with oracle over the disclosure requirements
19:54:01 <jmw> ryeng: we don't want to end up with both teams waiting for each other though, so anything proactive you can do to oil the wheels would probably be appreciated all round
19:54:45 <nthykier> Is there any chance the Oracle policy change can be more iterative/agile?
19:55:03 <jmw> ah nthykier has the buzzwords I am missing :)
19:56:17 <ryeng> I doubt it. We don't want to change policies all the time, so it will be one change in policy. Once we get some requirements, we can go back and forth a bit trying to find a specific solutions if there are options.
19:56:41 <rbasak> So there's "policy change", and "policy change process".
19:57:04 <rbasak> I don't think there's anyone here saying that the process cannot have some back and forthing, but I do think we need a written starting point.
19:57:46 <nthykier> ok :)  Figured it was worth a shot :)
19:58:00 <rbasak> My concern is that Oracle will do something, say "we've done it", and what they did won't be acceptable to Debian.
19:58:15 <rbasak> I want to avoid that, since all our efforts would be wasted.
19:58:22 <rbasak> (and we'd run out of time)
19:58:40 <nthykier> rbasak: you mean "if they only get the requireents little by little"?
19:58:45 <nthykier> requirements*
19:58:46 <rbasak> So I think it needs to start by Debian setting out its requirements, so I really appreciate that the security team are working on that now.
19:58:58 <jmw> I wonder if jmm_ or carnil carnil_ or Corsac are around and might be able to give an idea of what stage this is at
19:59:16 <Corsac> hhm?
19:59:18 <jmw> aha
19:59:27 <nthykier> jmw: I heard from jmm that he did not expect to be around
19:59:38 <jmw> nthykier: yeh it was a long shot
20:00:01 <jmw> Corsac: we are discussing mysql + security disclosures, and there's a rumour that the security team are working on some guidelines for disclosure requirements
20:00:16 <jmw> if it's news to you as well it's fine :)
20:01:02 <rbasak> jmm_ mentioned it earlier in this channel I think, before the meeting.
20:01:07 <Corsac> I'm not around either, and to be honest: the threads are way to large, with way too long mails (including the “summary” ones); so I'm definitely not aware enough
20:01:39 <jmw> ok, not to worry
20:01:43 <jmw> thanks
20:01:58 <rbasak> He said they've started, but it wouldn't be ready for this meeting.
20:02:12 <jmw> let's await developments there then
20:02:29 <otto_> (FYI: I'll be in FOSDEM this weekend if anybody wants to work on any MariaDB issues with me in person)
20:03:53 <jmw> on a different note, I have skimmed #811428 just now and this seems much more productive than on previous occasions, so assuming that continues I think I have much less concern about maintenance in stable for mysql
20:04:00 <nthykier> I am considering to add "[#]info The general feeling is that Oracle is unlikely to implement the desired result unless the full requirement list is given at once." - does that seem accurate enough / worded correctly
20:05:11 <ryeng> I'd say we're unlikely to hit the mark unless we have the full requirement list
20:06:07 <rbasak> jmw: thanks. Oracle worked hard to make that happen since it was brought up, so I appreciate you noticing!
20:06:08 <nthykier> ryeng: ok
20:06:11 <ryeng> You're the ones pushing for change, so we'll try to adapt to what we get from you. If that's not a complete list, it may not be a complete solution.
20:06:49 <nthykier> #info Oracle believes they are unlikely to hit the mark unless they got a full requirement list
20:06:50 <jmw> nthykier: how about $agree it's not reasonable for oracle to implement a moving set of requirements at short notice, so we await a more concrete set of guidelines to negotiate with
20:07:00 <jmw> or that
20:07:05 <nthykier> jmw: wfm
20:07:12 <jmw> will you do it?
20:07:27 <jmw> or we'll end up with two :)
20:07:41 <nthykier> will do
20:08:07 <nthykier> #agree It is not reasonable for Oracle to implement a moving set of requirements at short notice.  We will await a more concrete set of guidelines to negotiate with.
20:08:10 <jmw> otto_: I couldn't find a similar bug for the mariadb dsa recently, was there much discussion about that or did it just work?
20:09:12 <nthykier> ryeng: Do you know if this has high priority within Oracle in general?
20:09:39 <otto_> There was no separate bug report, we just documented the CVE in the package changelog and initial trigger to upload happened with Oracle CPU coming out
20:10:04 <ryeng> nthykier: It does, high up.
20:11:02 <jmw> otto_: ok, thanks
20:11:07 <nthykier> :)
20:11:53 <otto_> jmw: from this page you find the best links to more info: https://security-tracker.debian.org/tracker/CVE-2016-2047
20:12:42 <jmw> can I take it we're agreed that the maintenance issue isn't a big one any longer, and we can put that objection aside?
20:13:26 <jmw> jcristau: your opinion valued on that point, with your SRM hat on
20:14:10 <jcristau> i have no information on that.  don't know.
20:14:29 <nthykier> If it continues like #811428 I do not have any immediate concerns - I cannot speak for the security team nor the SRMs
20:14:47 <jmw> well, I mean maintenance in {old,}stable specifically
20:15:24 <jcristau> SRM hasn't been involved in any of that so far afaik.  they're all through security.
20:16:32 <nthykier> (concerns over the how, though it is still new upstream releases)
20:16:35 <jmw> ok
20:17:21 <jmw> #agreed the security release process seems much improved, but a longer view should be taken about overall maintenance in stable
20:17:32 <jmw> I guess there isn't likely to be much non-security stable maintenance
20:18:13 <jmw> #action jmw will mail the security team to see how things are going with DSAs
20:18:29 <jmw> now this question of "defaults"
20:19:35 <Corsac> jmw: please keep mail *short*; we're already overwhelmed by mail for actually handling/triaging security issues, embargoed or not
20:19:46 <jmw> Corsac: sure thing
20:21:28 <jmw> defaults: we have a finite window in which to make package dependency changes to effectively default one engine over the other for packages which just don't care (the libmysqlclient problem)
20:22:20 <jmw> there is a virtual mysql package at the moment as well, isn't there? (I'm not so clear on this bit)
20:22:51 <rbasak> I believe there's virtual-mysql-server, provided by both mysql-server and mariadb-server, or something like that.
20:23:00 <rbasak> otto_ knows more I think.
20:23:32 <otto_> https://wiki.debian.org/Teams/MySQL/virtual-mysql-server
20:23:41 <rbasak> libmysqlclient is an entirely separate thing I think. It'll take some care and coordination, since the MariaDB build of it is different from the MySQL build of it (same soname)
20:24:12 <rbasak> AIUI, MariaDB aren't progressing libmysqlclient at all. Instead they have a separate client library that they work on, with a separate soname.
20:24:17 <otto_> maraidb.org repos ship libmariadbclient18 and all software seems to work OK with it
20:24:45 <otto_> libmariadbclient18 is designed to be a drop-in-replacement for libmysqlclietn18
20:24:47 <ryeng> rbasak: Correct, MariaDB Corp. are developing a separate library: https://lists.launchpad.net/maria-developers/msg09042.html
20:25:10 <ryeng> According to them, libmysqlclient in MariaDB is not actively maintained
20:25:21 <otto_> All new developments I think is in libmariadb2 and libmariadb3, which is natural
20:25:51 <ryeng> otto_: Yes, if switching library, it would be natural to use that instead of libmysqlclient from MariaDB.
20:25:56 <rbasak> otto_: is libmariadb3 also a client library?
20:26:15 <rbasak> I hear three names - libmysqlclient, libmariadbclient, and libmariadb.
20:26:31 <rbasak> I'm a bit confused as to MariaDB's position on the first two.
20:26:43 <otto_> Switch to a new library (eg libmaria2) I think needs something from the app developer to do, at minimum change soname they link to
20:26:44 <rbasak> Are they the same?
20:27:12 <otto_> Switch to libmariadbclient18 package provided libmysqlclient.so.18 would not require any extra work
20:27:45 <rbasak> Any ABI differences?
20:28:05 <rbasak> It doesn't feel right to me that MariaDB is taking over the same soname, but that's up to the release team I suppose.
20:28:22 <rbasak> It might be cleaner to get dependent packages to explicitly build against a new soname perhaps?
20:28:55 <otto_> SUSE and RedHat migrated all existing software to build against MariaDB provided version of libmysqlclient
20:28:58 <ryeng> libmysqlclient in MySQL and MariaDB are very similar, but there may be a few issues with 5.6 features and newer, since that happened after the fork.
20:29:59 <rbasak> otto_: what soname do SUSE and RedHat use?
20:30:18 <otto_> The ABI is not 100% same in mysql-5.5/libmysqlclient.so.18 and mysql-5.6/libmysqlclient.so.18 and mariadb-*/libmysqlclient.so.18
20:30:40 <otto_> ..but with regard of compatibility they are the same
20:30:41 <nthykier> ryeng: But the libmariadbclient.so.18 implements these features?
20:30:53 <otto_> MariaDB has some extra async functions
20:31:16 <nthykier> ("these features" being the 5.6 features)
20:31:58 <ryeng> nthykier: I'm not sure what libmariadbclient.so.18 is. If it's libmysqlclient.so.18 as shipped by MariaDB, it doesn't implement all features in libmysqlclient.so.18 as shipped by MySQL.
20:31:59 <otto_> This is the rule of thumb: mysql-5.5=mariadb-5.5, mysql-5.6=mariadb-10.0
20:32:30 <nthykier> otto_: ack, thanks
20:33:10 <nthykier> ryeng: ok - guess I will have to ask otto_ :)
20:33:31 <otto_> but they all have the soname .18 by Oracle design - only in 5.7 Oracle bumped to so.20
20:33:36 <jmw> am I right in saying that the major problem we need to solve is whether to ship variants, rather than which one gets preferred by applications?
20:33:40 <jcristau> wrt libraries and SONAMEs, i don't think rule of thumb is enough.  it sounds like if we switch packages to use mariadb-provided libmysqlclient, it should have a different SONAME.
20:33:56 <jcristau> and not pretend to be something it's not
20:34:38 <jcristau> the -dev package could still ship libmysqlclient.so, to keep API the same.
20:34:43 <otto_> jcristau: If that rule is followed to the letter, then the SONAME in mysql-5.6 should urgently be changed to .19
20:34:55 <jcristau> otto_: nope
20:35:20 <rbasak> otto_: right, and Oracle kindly reserved .19 for Debian for this purpose.
20:35:42 <otto_> jep, but not implemented yet as nobody requested it hard enough
20:35:50 <rbasak> We decided not to do it because we thought it was the lesser of two evils, given the timing.
20:36:22 <rbasak> But I'm happy to fix it that way if the release team require it. That's not a policy problem in my mind, just a bug that needs to be fixed.
20:36:43 <jcristau> otto_: if something built against libmysqlclient from mysql 5.5 would still work with libmysqlclient.so.18 from 5.6, there's no need to change SONAMEs.  but with two parallel branches, keeping oracle's SONAME sounds like a recipe for trouble
20:36:44 <otto_> Equally the lesser of two evils in migration to libmariadb.so.18 would be to keep the SONAME
20:37:36 <jcristau> anyway.  dinner time.
20:37:53 <rbasak> otto_: I think that introduces potential future problems because you end up with two owners of the same soname. For example, what happens if Oracle's disclosure policy gets fixed to Debian's satisfaction, and then Oracle want an 18.1 or 19?
20:37:54 <otto_> jcristau: Yes, the Debian repositories should not have two providers of libmysqlclient.so.18, thus MariaDB in Debian does not ship any libmariadbclient package from teh mariadb server source as mysql does
20:37:59 <rbasak> (or 20, which they have)
20:39:02 <otto_> I am just replying to jmw question: can the client library "default" switched? Yes if release team wants.
20:39:33 <jcristau> ok
20:40:16 <jmw> otto_: that wasn't quite what I meant, let me rephrase it
20:41:13 <jmw> the disagreement between mysql and release teams is about whether to ship a particular variant or not, rather than the "default", right? for example, shipping mariadb but not mysql
20:41:33 <jmw> and the mysql team's position is that you want to ship both in parallel
20:41:47 <rbasak> jmw: right. We want to ship both, you (and/or security) want to remove one.
20:41:51 <rbasak> That's my understanding.
20:41:55 <jmw> ok good
20:42:24 <otto_> If there is only one option, then we don't need to have a discussion of what is the "default"
20:42:32 <jmw> I'm coming to that
20:43:16 <jmw> the major concern from our point of view is the amount of time there is remaining to do the technical work *if* one variant ends up dropped because it lacks support from the security team, for whatever reason
20:44:07 <jmw> I don't think it's disputed that mysql is currently the issue there, rather than mariadb (the security team certainly have that preference, afaik)
20:44:32 <rbasak> I agree in part.
20:44:48 <rbasak> There's no dispute that it's MySQL facing the cut here.
20:45:03 <rbasak> But I think there is dispute that it's being done on sound technical reasons, rather than political feeling.
20:45:48 <rbasak> Since, for example, security disclosure issues *impact* both variants, as we discussed earlier.
20:46:08 <jmw> ok, noted, although security support is largely out of our hands (we have no desire to ship something without security team support)
20:46:35 <rbasak> I understand that you can only proceed on the decision of the security team.
20:47:00 <rbasak> I think that the security team owe us an answer on this point, which is distinct and separate from the progress on getting Oracle to change their policy.
20:47:11 <otto_> Currently we have worked to have both side-by-side. Inside the team we cannot of course agree that either one should be defalt in any way, and thus technically Debian users have as much freedom to choose right now as possible. Which is a positive thing.
20:48:32 <jmw> meanwhile the freeze marches nearer, and one idea I recently heard was to start the process of switching dependencies towards mariadb clients in anticipation of a problem. this would not mean that we don't do everything we can to ship both side by side, but it lessens the crunch quite a lot in november when we suddenly have to get on with it
20:48:53 <jmw> shipping in parallel would be ideal, but this keeps the options open
20:49:23 <nthykier> jmw: It is november - 2 months (assuming this to be a transition)
20:49:27 <rbasak> As an aside, two packages come to mind. akonadi and pinba-engine-mysql. They have deeper integration with MySQL than most.
20:49:30 <jmw> nthykier: yes
20:49:51 <rbasak> If there are issues switching, I think those are more likely to have issues than some of the others.
20:50:06 <rbasak> I haven't done any real analysis though. That's just off the top of my head.
20:51:04 <ryeng> rbasak: Yes, those and ... and MP3 player I don't remember the name of just now, which uses the embedded server lib.
20:51:09 <otto_> I don't know pinba but there was at least one user running akonadi with mariadb-server-core-10.0 package installed and reported it to work
20:51:23 <rbasak> jmw: I wonder. Could you agree to ship both, if and when the security team considers its cocnerns addressed?
20:51:56 <rbasak> jmw: because if you can, that might make it more likely to get a favourable result (from Debian's perspective) on the disclosure issue.
20:53:10 <jmw> well, I'm pretty sure shipping mysql in stretch is less disruption all round. not sure whether I would want to commit to it right here and now though, although I'm not against it
20:53:15 <jmw> I wonder what nthykier thinks
20:54:41 <jmw> (brb)
20:56:05 <otto_> (I need to go to bed soon, early morning and long travel day tomorrow..)
20:56:13 <nthykier> otto_: ack
20:57:01 <nthykier> Personally, I am not against shipping both based on the assumption that every thing works out on the security disclosure transparancy part.
20:57:51 <nthykier> Though, I like jmw I am not comfortable with commiting to ship both right here and now
20:58:41 <rbasak> I understand that there may be other reasons that crop up, and wouldn't expect you to be restrained by those.
20:58:55 <rbasak> I wonder if there's some sort of statement in the middle that you can make.
20:59:00 <rbasak> I don't know what.
20:59:59 <rbasak> My thinking is that if Oracle face "meet these requirements and the problem is solved", that's better than facing "meet this requirements and we'll think about it". The former is much more likely to get us a favourable result, IYSWIM.
21:00:15 <jmw> rbasak: we certainly can't commit the team to it between the two of us (especially not SRMs), but I'm inclined to be upbeat
21:00:27 <jmw> the security team objection is by far the biggest factor
21:00:58 <jmw> SRM's concern will be/is long-term maintenance; there are at least three years worth
21:01:43 <jmw> so returning to the question of switching clients early in anticipation
21:02:15 <rbasak> There are clients, depending on libmysqlclient18. And there are things that need servers, depending on mysql-server-5.6 or mysql-server-5.6-core.
21:02:25 <rbasak> Anything else?
21:02:40 <rbasak> ryeng: mentioned an MP3 client.
21:02:59 <rbasak> pinba-engine-mysql build-depends on mysql-server-source (binary)
21:03:44 <ryeng> cqrlog
21:03:47 <rbasak> pinba-engine-mysql might be a good place to start, actually. If it's blocked, then the release team will need to make a decision about what to do with it.
21:03:54 <jmw> what I'm getting at is should we start that process *now*
21:04:13 <jmw> or dither and hope we don't have to do it at all
21:04:58 <otto_> there is by the way already packages with "Depends: mariadb-server | virtual-mysql-server"
21:05:10 <nthykier> Certainly biased, but I am in favor of starting the process *now*.   My greatest motivation being risk reduction
21:05:40 <otto_> But it is of course a different scale if release team sets it as a goal for all mysql depending pacakges
21:05:41 <rbasak> If MySQL eventually gets leave to remain, what would happen then?
21:05:42 <nthykier> s/reatest/primary/ ?
21:05:57 <rbasak> I presume that right now the release team will set the goal, and later on let maintainers do what they wish again?
21:07:09 <jmw> I guess - given we haven't worked this out yet - that we would file non-rc bugs requesting a switch, and when we know for sure what the outcome will be either make them RC or relax
21:07:16 <jmw> something along those lines, probably
21:07:33 <rbasak> Understood, thanks.
21:08:11 <rbasak> I'd appreciate the opportunity to provide some feedback on the text of that bug.
21:08:22 <jmw> certainly, if and when the time comes
21:08:29 <rbasak> Thanks
21:08:49 <jmw> to be honest, pkg-mysql-maint would be in a better position to drive that process in general, knowing the packages better
21:08:56 <jmw> but we can sort that later
21:10:03 <jmw> I must admit starting that process and leaving time for fixups appeals to me as it does nthykier (and I think jcristau too)
21:11:01 <jmw> we should move this to mail so that the rest of the teams can get involved:
21:11:04 <otto_> If the release team makes a clear announcement somewhere I can then implement what was requested
21:11:21 <otto_> (file bugs about virtual-mysql-* preference)
21:12:01 <otto_> Something else? We can't touch libmysqlclient.so.18 now and there might not be a need to do it ever?
21:12:34 <rbasak> jmw: I'm not really clear on how the release team works on this kind of thing. What's necessary to get a release team decision? Eg. majority vote, a leader, or something else?
21:13:09 <jmw> #info it may be wise to start migration towards mariadb dependencies sooner rather than later, but ship mysql as well if security concerns are resolved
21:13:24 <jmw> #info a decision cannot be taken right now
21:13:27 <nthykier> rbasak: If we had been more, we would probably have voted over IRC
21:13:33 <rbasak> otto_: I imagine that it'd be a virtual-mysql-* preference together with an instruction to build against libmaria* and drop libmysqlclient dependency?
21:13:48 <nthykier> rbasak: but we appear to be 2 (maybe 3), so I think we will vote over email
21:13:49 <jmw> #action jmw will mail release team and include pkg-mysql-maint about moving to mariadb dependencies
21:13:56 <jmw> quite
21:14:03 <rbasak> OK, thanks.
21:14:15 <jmw> we don't usually have to resort to voting and can reach consensus, but nthykier and I certainly can't decide this on our own
21:14:33 <jmw> I think we should wrap mysql up there; we have made some progress and have some actions
21:14:47 <jmw> rbasak otto_ ryeng thanks for your contributions
21:15:03 <ryeng> jmw: thank you
21:15:04 <nthykier> tsk, you forgot ltangvald :)
21:15:16 <jmw> ah i was just trying to find him in scrollback :)
21:15:19 <ltangvald> Shh, I'm not part of the political talk :D
21:15:26 <rbasak> :)
21:15:29 <nthykier> hahaha
21:15:32 <jmw> ltangvald, thanks for your non-political contributions :)
21:15:43 <rbasak> And thank you for the time from the release and security teams on this.
21:15:54 <otto_> Thanks and good night! (now or later today :))
21:15:57 <ltangvald> Yes, thank you!
21:16:05 <ryeng> If anyone wants to talk face to face, both Otto and I will be at FOSDEM. Just reach out.
21:16:12 <jmw> nthykier: so we have a few things left on the agenda, but it's getting on:
21:16:29 <jmw> reproducible builds: I feel bad pushing that back another month :s
21:16:53 <jmw> they were keen for a discussion before christmas even
21:17:16 <nthykier> jmw: Ok with me :)
21:17:40 <jmw> h01ger: we have not forgotten you
21:17:51 <jmw> I will put move it to the top of the agenda for next time perhaps
21:18:09 <jmw> nthykier: mips64el, do you know what that is about?
21:18:22 <nthykier> next to nothing
21:18:27 <jmw> ok we'll defer that
21:18:36 <jmw> and linux in stretch only arrived this evening, that can wait
21:18:44 <jmw> I might see ben next month anyway
21:18:52 <jmw> #topic Next meeting
21:19:23 <jmw> according to my calendar it's 24th Feb next, does that sound right?
21:20:08 <nthykier> Yupe - my calendar also says Feb 24th
21:20:16 <jmw> #info Next meeting: 24th February 2016
21:20:28 <jmw> I will do the usual
21:20:31 <jmw> #topic AOB
21:20:35 <jmw> any other business?
21:20:58 <nthykier> nope
21:21:07 <KiBi> not from me (apologies as well, only slowly coming back to #-release stuff)
21:21:22 <jmw> ok, let's leave it there
21:21:23 <jmw> #endmeeting
21:21:36 <nthykier> #endmeeting