diff options
Diffstat (limited to 'meeting-logs/20160214.txt')
| -rw-r--r-- | meeting-logs/20160214.txt | 539 |
1 files changed, 539 insertions, 0 deletions
diff --git a/meeting-logs/20160214.txt b/meeting-logs/20160214.txt new file mode 100644 index 0000000..fad1b46 --- /dev/null +++ b/meeting-logs/20160214.txt @@ -0,0 +1,539 @@ +20:01:59 WilliamH: Who is chairing? +20:02:20 jlec: *is* +20:02:28 jlec: !proj council +20:02:29 willikins: (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh +20:02:32 ulm: *here* +20:02:34 K_F: *here* +20:02:35 blueness: *here* +20:02:36 rich0: *here* +20:02:39 jlec: *here* +20:03:07 jlec: dilfridge aound? +20:03:26 dilfridge: present +20:03:31 WilliamH: *here* +20:03:35 jlec: nice +20:03:38 jlec: Let's start then +20:03:49 jlec: Topic one +20:03:50 jlec: Options for new XML validation language [0][1] +20:03:57 jlec: [0] https://archives.gentoo.org/gentoo-project/message/3ebf4ccf0d4f27d6240888a3100d0d58 +[1] https://archives.gentoo.org/gentoo-project/message/fa05f5319ef4255d3e3fe34da79a2534 +20:05:15 jlec: Do we want to suggest the usage of a specific validation language? +20:05:36 ulm: I'd be all in favour of replacing dtd by relax ng +20:05:43 K_F: it sounds prudent to do so, but before going with a suggestion, what is the background for a new one to begin with? +20:05:55 K_F: lack of flexibility / difficulty maintaing DTD? +20:06:25 ulm: apparently dtd cannot express everything we need +20:06:30 blueness: ulm: have you written the validation in relax ng yet? +20:06:32 jlec: As far as I get it, telax ng is just easer to work with, with basically no functional drawbacks on our current system +20:06:37 blueness: i’m only familiar with dtd +20:07:07 dilfridge: *has no clue about either and therefore abstains w/r this topic* +20:07:09 ulm: e.g. in metadata.xml <maintainer type="foo" /> can only have one list of types +20:07:26 ulm: but we need a different one for upstream maintainers +20:07:52 ulm: blueness: djc has volunteered +20:08:03 ulm: for relax ng, that is +20:08:41 blueness: honestly i don’t care as long as it works, i’m not sure what this propagated up to the council, i saw a debate but didn’t see any hard opinions +20:08:57 jlec: ulm: so basically relax ng would be a step forward, if not even needed for our porblems. Are you aware of any drawbacks or problem which can come up? +20:09:29 ulm: there are conversion tools which basically work +20:10:02 ulm: but IIUC not between any pair of formats +20:10:16 ulm: I'm far from being an expert, though +20:10:18 K_F: jlec: it was mentioned that cross-referencing doesn't work in relax ng in the email +20:10:50 ulm: do we need that for our formats? +20:11:18 K_F: my understanding from reading the source documents and some external sources , XML Schema is more flexible and advanced, but that brings complexity and is more difficult to maintain +20:11:55 K_F: ulm: not sure to what extent it applies to e.g project mapping to members and sub-projects +20:12:16 jlec: mgorny: do we need the cross-ref support for our formats? +20:12:32 jlec: Does dtd support that? +20:12:44 mgorny: dtd doesn't support anything ;-p +20:12:53 K_F: jlec: DTD doesn't support it, but it might be interesting for relax ng vs xml schema question +20:12:54 mgorny: as for cross-ref, it depends on what we actually want to do with them +20:12:58 jlec: so what ever we choose it will be better +20:13:14 mgorny: as i see it, the goal should be to provide readable metadata.xml syntax checks +20:13:19 mgorny: if schema can do that, nice +20:13:26 mgorny: if it can't, we should implement it in python +20:14:22 WilliamH: I'm not sure we have anough information to make a decision on this/ +20:14:29 WilliamH: enough * +20:14:33 mgorny: to be honest, i want to do some research with all three formats and see how bad is the output of various validators +20:14:48 dilfridge: that sounds like a good plan +20:14:51 K_F: WilliamH: I agree, I'm not comfortable making a vote on a specific decision at this point, so propose we make this a discussion topic and bring it back to ML again before an actual decission +20:14:55 ulm: I had also brought up that there are few converters accepting xml schema as input: https://archives.gentoo.org/gentoo-project/message/6fb9132fc6ea31554885da68efcfa8d7 +20:15:37 WilliamH: *agrees with K_F, this isn't ready for a vote.* +20:15:44 K_F: ulm: My understanding of the reason for that is that is has more complexity than the alternative solutions +20:15:49 jlec: So let's request some more precise measures on which we can base our decision on. +20:15:57 K_F: so that might not be a fair fair disadvantage in the end +20:16:11 jlec: And I like to hear what tools will be broken before we decide on a change this time +dilfridge has changed the topic to: Next meeting: 2016-02-14 19:00 UTC | http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160214T19 | https://wiki.gentoo.org/wiki/Project:Council | Agenda: https://archives.gentoo.org/gentoo-project/message/ad76ad39e419a9522d6f550166b39ab2 (20:16:13) +20:16:45 K_F: jlec: as it doesn't break the xml itself, very few tools should be affected +20:16:58 rich0: I'm certainly not married to the current implementation and am fine with changing it - but perhaps those with a vested interest need to just work out the rest? I don't think it necessarily needs council approval but I'm fine with it. +20:17:03 mgorny: as a side note, maybe we should remove <!DOCTYPE from metadata.xml files +20:17:42 jlec: K_F: Doesn't matter. I would like to have a full list for so that we can make maintainers aware this time +20:18:00 WilliamH: mgorny: I don't think we can remove <!DOCTYPE +20:18:08 mgorny: repoman downloads DTD directly anyway, and this would avoid binding it to a specific schema format +20:18:21 mgorny: or at least having repoman complain when we change http:// to https:// +20:18:40 jlec: Let's focus on the future and then see what changes we need in metadata.xml for that +20:19:00 K_F: rich0: as for the point of council decision, I think it is warranted as we should be using the same schema across the gentoo tree/projects +20:19:14 K_F: as it is a global change, it seems prudent +20:19:22 WilliamH: jlec: wrt the list of tools, I don't think that should be a blocker. +20:19:37 rich0: K_F: perhaps, but I think issues really only need approval if there is controversy after they are announced. +20:19:51 K_F: WilliamH: but if there is any problem, at least a heads up and timely implementation +20:19:54 WilliamH: jlec: It's up to the maintainers to fix their tools if they break. +20:19:55 rich0: This is a relatively large change though +20:19:57 dilfridge: WilliamH: it should be, since otherwise the drama just restarts again +20:20:10 ulm: WilliamH: if they are fixable +20:20:14 WilliamH: dilfridge: we can deal w/ the drama other ways? +20:20:28 dilfridge: we're happy with long deprecation times, so why can't we plan properly in advance here? +20:20:42 rich0: I agree with WilliamH. By all means have a bug and blockers, but I don't think that it needs to be resolved if we set a reasonable deadline. +20:20:56 K_F: rich0: I'd agree with that +20:21:11 WilliamH: *thinks we have some devs who live on controversy * +20:21:12 dilfridge: WilliamH: we can deal with it, but I dont want to. +20:21:14 rich0: I'm fine with a deprecation period that is reasonable +20:21:46 rich0: In general though I don't like putting 100% of the burden of any improvement on the volunteers who are doing the improvement. There needs to be a reasonable balance. +20:21:53 dilfridge: yes +20:22:02 K_F: rich0: indeed +20:22:12 dilfridge: put up a reasonable timeframe and afterwards go ahead +20:22:24 dilfridge: and whoever complains afterwards gets ignored  +20:22:30 K_F: I'd actually appreciate a list of specific issues that can't be solved with current setup of DTD as well +20:22:34 WilliamH: dilfridge: the problem is, what's reasonable? +20:22:43 K_F: so that we have it in the archives for rationale for switch +20:22:50 dilfridge: but the reasonable timeframe needs first identification of the problems +20:22:58 dilfridge: so at least that should be done +20:23:00 WilliamH: dilfridge: in our last case, we gave a reasonable time, but no one acted. +20:23:09 dilfridge: ie. tracker bug +20:23:24 K_F: tracker bug and individual reports seems prudent way to go +20:23:32 dilfridge: did anyone file a tracker bug for herds.xml removal? +20:23:41 dilfridge: xiaomiao: ^ +20:24:04 WilliamH: I never saw one. +20:24:27 WilliamH: That doesn't mean it wasn't filed I guess, but I didn't see it. +20:24:27 dilfridge: me neither. +20:24:30 mgorny: was there any bug to put on the tracker? +20:24:36 ulm: dilfridge: maybe there are no issues known? +20:24:57 dilfridge: well, that would invalidate an entire mailing list thread +20:25:00 K_F: ulm: a few complaints have surfaced afterwards at least, so lets try to avoid that going forwards +20:25:00 mgorny: oh wait +20:25:04 mgorny: https://bugs.gentoo.org/show_bug.cgi?id=glep67-tracker +20:25:07 WilliamH: The problem would be that you would have had to open individual bug reports on each package in the tree +20:25:47 mgorny: there's even separate bug for herds.xml/herds.dtd removal +20:26:01 ulm: bug 573010 +20:26:04 willikins: https://bugs.gentoo.org/573010 "herds.xml and herds.dtd removal"; Gentoo Infrastructure, Other; CONF; ulm:infra-bugs +20:26:05 K_F: mgorny: but it was filed after the implementation date  +20:26:17 rich0: K_F: as long as there is reasonable notice/etc I think we're doing things reasonably. We're NEVER going to avoid having a few complaints surfacing on lists when we make a change. +20:26:32 WilliamH: ok so there was one for glep67 +20:26:34 K_F: rich0: my thoughts exactly +20:26:47 dilfridge: rich0++ +20:26:49 rich0: *notes that his reasonable statement was reasonable - he should become an attorney.* +20:27:28 WilliamH: *agrees with rich0* +20:27:38 blueness: hmm … will all the overlays have to change their metadata.xml individually (side note) +20:27:45 WilliamH: Like I said earlier we seem to have some folks who live to complain  +20:27:46 K_F: so we should do some work to determine which packages would be affected by such a switch and create a tracker bug for it, give reasonable deprecation period before switch.. but other than that I'm fine with a switch so long as we: +20:27:59 ulm: blueness: that's independent of herds.xml +20:28:08 blueness: ulm: k +20:28:14 K_F: (i) gain new features / stability / easability of maintenance from it and (ii) get more info on what language we should switch to +20:28:29 mgorny: i have offered to file bugs for overlays needing <herd/> removal +20:28:34 mgorny: but that would be over 260 bugs, afair +20:29:02 K_F: our main concern should be the gentoo tree +20:29:08 blueness: mgorny: yeah i just noticed all the validation errors on the musl overlay +20:29:13 blueness: that’s going to be annoying +20:29:15 dilfridge: mgorny: do we have something like an "overlay owners mailing list"? +20:29:19 WilliamH: K_F: right, overlays aren't our concern +20:29:21 mgorny: dilfridge: nope +20:29:27 K_F: dilfridge: that might be a good idea to have +20:29:31 dilfridge: would be useful for such a case +20:29:31 mgorny: some overlays don't even have bugzilla account associated +20:29:31 K_F: or rather +20:29:35 K_F: overlay-owners-announce +20:29:47 mgorny: dilfridge: i'd say gentoo-dev-announce is quite appropriate there +20:29:53 K_F: with low-traffic that overlay owners can sign up to and we can make announcement affecting them +20:29:56 mgorny: since it covers various topics related to ebuild maintenance +20:30:13 WilliamH: g-d-a seems reasonable +20:30:20 dilfridge: s/can/must/ if on git.gentoo.org +20:30:25 dilfridge: or in layman +20:30:35 rich0: I tend to think g-d-a is fine, but by all means suggest otherwise on the lists and see how much interest there is. +20:30:54 WilliamH: We don't need to create a ml just for overlay owners. +20:31:02 dilfridge: gentlemen, we're taking far too long to decide that we dont want to decide something today +20:31:03 K_F: maybe there should be a recommendation to sign up to the list in the wiki page for overlays +20:31:04 WilliamH: They might want the last rites messages etc +20:31:09 WilliamH: those go to g-d-a +20:31:30 WilliamH: *agrees, let's move on* +20:31:45 K_F: dilfridge: agreed, I support deferring +20:31:47 jlec: Do we need to vote on postponing? +20:31:56 dilfridge: nah +20:31:57 WilliamH: no +20:31:59 ulm: nope +20:32:05 jlec: 2) Discuss situtation of libressl support maintenance [2] +20:32:08 WilliamH: let's move on  +20:32:11 jlec: [2] +https://archives.gentoo.org/gentoo-project/message/dc5406af670aebc050362fcbd8cd528e +20:32:29 jlec: blueness, your turn +20:32:33 blueness: okay +20:32:50 blueness: i looked over everything hasufell left behind +20:33:07 blueness: and we can take care of most of his packages in the usual way, just co-maintain +20:33:08 blueness: etc +20:33:24 blueness: but libressl is 1/2 in the tree, its as much work to continue adding as it is to remove +20:33:30 blueness: take a look at the transition plan +20:33:39 blueness: https://github.com/gentoo/libressl/wiki/Transition-plan +20:33:56 blueness: that’s where the real work is +20:34:18 blueness: what i’d like to do is have individual devs add libressl to their packages if they’re on that list +20:34:22 mgorny: i've helped him with planning that and the idea is pretty solid +20:34:25 blueness: its easy but there’s a lot +20:34:39 blueness: mgorny: yeah it looks good to me and i’ve been working through it +20:34:44 blueness: but there’s a lot +20:34:45 K_F: well, arguably the real work is maintaining two separate security sensitive crypto libraries for both maintainers and security project +20:34:50 dilfridge: looks technically sound, yes +20:34:56 mgorny: the most important problem is that you can't install both at the same time +20:35:05 Soap__: blueness: whats the plan for packages relying on openssl-1.0.2 API? +20:35:06 mgorny: so you'd have to fix all packages on your system to test it properly +20:35:07 mgorny: or hack +20:36:09 ulm: blueness: what exactly are you expecting the council to do here? +20:36:22 blueness: so what do you think if the council ask developers to add libressl support as per that page to their own packages, and i’ll take care of fixing libressl related bugs +20:36:22 blueness: so the only onus on devs is to just add the dependency +20:36:30 blueness: ulm: just ask developers to take on the task politely  +20:36:33 WilliamH: blueness: it sounds like you have a reasonable plan, so I was going to ask the same question. +20:36:36 blueness: i mean i don’t want to force people +20:36:59 K_F: blueness: I'm not comfortable adding the deps to the packages I maintain at this point since it increase complexity if there is API divergence +20:37:00 mgorny: maybe it'd be useful to have a blessing to fix packages without going through maintainers, at least when it doesn't require patching +20:37:13 jlec: AS I see it, we just need to have an active libressl project team +20:37:14 K_F: and if I add that as maintainer I'm forced to try to find solutions that might not be upstream-compatible +20:37:23 monsieurp: +1 jlec +20:37:31 jlec: !proj libressl +20:37:31 willikins: jlec: No such project: libressl@gentoo.org +20:37:36 blueness: mgorny: i’m willing to do that +20:37:37 monsieurp: jlec: I asked about this issue a while ago  +20:37:45 K_F: jlec: exactly, without a libressl project that is difficult to rely on as there is noone with special knowledge to provide patches for such issues +20:38:04 mgorny: *finds it funny to have libressl project without openssl project ;-p* +20:38:04 ulm: blueness: any chance that upstreams will merge again in the future? +20:38:21 blueness: ulm: doubtful +20:38:32 ulm: technical reasons? +20:38:34 jlec: So I personally don't care about libressl, but also don't mind if there is a fix needed for packages I maintain. +20:38:41 rich0: I don't have a problem with the libressl project (once it exists) adapting ebuilds to have libressl support, as long as they're willing to deal with bugs/etc that result. Due to the inability to install in parallel it makes it a bit of a pain to test/etc. +20:39:00 K_F: jlec: but who is responsible when a bug appears due to API divergence? +20:39:06 mgorny: ulm: both technical and political +20:39:07 blueness: ulm: the openbsd people were pretty agressive against ssl3 because of security issues, i’m not sure how they would ever match up gain +20:39:10 K_F: jlec: or can provide support for it +20:39:16 dilfridge: K_F: you end up with versioned dependencies +20:39:21 mgorny: openssl is the worst API i've ever seen +20:39:35 jlec: K_F: I would say, openssl rules over libressl. In such a case, libressl needs to go +20:39:36 blueness: K_F: i’ll take on the responsibility for api divergence +20:39:40 K_F: dilfridge: but they need to be written by someone +20:39:44 mgorny: libressl... maybe i'll be able to convince them to fix it +20:39:44 blueness: (its the story of my life with eudev  +20:39:46 K_F: jlec: but it can't as it share the same SO name +20:39:54 K_F: jlec: so it is all-or-nothing if switch +20:39:56 dilfridge: K_F: same as with ffmpeg / libav +20:40:06 K_F: dilfridge: exactly the situation I'm quite unhappy with +20:40:16 K_F: dilfridge: but worse, since it is security critical package +20:40:18 K_F: far worse.. +20:40:22 blueness: mgorny: yeah openssl api is pretty vast and complex +20:40:35 mgorny: not that is the problem +20:40:45 mgorny: the problem is that it was written without much care for any sanity and left that way +20:40:47 jlec: Was there an official council decision when we started to introduce libressl support in gentoo.igt? +20:40:51 K_F: no +20:40:55 mgorny: like some modules use char*, some unsigned char* and almost never const +20:40:59 dilfridge: no and it wasnt really needed +20:41:16 jlec: Is it or not? +20:41:28 mgorny: K_F: i think that purely technically we could have libressl in a subdirectory of lib* with some RPATH hackery +20:41:33 mgorny: but that'd be hard +20:41:38 dilfridge: blargh +20:41:46 K_F: mgorny: yeah, we could also go nixos route with namespaces in theory +20:41:54 K_F: but it won't fit well into our current model +20:42:17 K_F: I'm principally not in favor of supporting forks that retain SO/library names +20:42:20 jlec: If not, I would just request a libressl project to excist, which takes over all responsibility. +20:42:26 blueness: K_F: youre shifting the focus to the api difference, but the issue is libressl is 1/2 the tree +20:42:28 blueness: so what do we do? +20:42:49 blueness: i suggest finishing it because its as much work to finish it as it is to take it out again, and it might be useful +20:42:59 dilfridge: blueness++ +20:43:01 blueness: and i’ll take care of bugs that are due to diffs in abi +20:43:03 rich0: K_F: even the nixos approach has issues - if you have something pull in two things which themselves use different ssl implementations you still mix the namespaces +20:43:12 K_F: rich0: yup +20:43:13 rich0: but it certainly improves things +20:43:52 monsieurp: blueness++ too but you can't take on this task on your own +20:43:52 jlec: So what should we suggest? +20:44:08 blueness: monsieurp: i may get help +20:44:10 WilliamH: blueness: I would say that diffs in abi have to be closed wontfix and the packages would only support openssl. +20:44:11 blueness: i could start a project +20:44:14 K_F: if the underlying question is manpower, I suggest starting a libressl project +20:44:19 K_F: and asking if people are interested in joining +20:44:26 jlec: a) having an official project, so people know who should be talked to, b) finishing the work in the tree. +20:44:27 WilliamH: *agrees w/ K_F * +20:44:40 K_F: that should give some idea about the manpower we have available if issues shows up (and it will) in the future due to divergence +20:44:45 WilliamH: *agrees with jlec * +20:44:45 blueness: K_F: the underlying problem is the transition, not the long term maintainance +20:44:51 K_F: blueness: I disagree +20:45:02 K_F: the transition shouldn't happen without a plan for long term maintenence +20:45:09 jlec: blueness: what is the problem with the transistion? +20:45:28 dilfridge: well. in the worst case mask the useflag and phase it out again. +20:45:30 rich0: I suggest form a libressl team and if they want to take it on, take it on. It isn't a crime to start something and decide not to finish it. +20:45:43 rich0: The people doing the work can decide whether the work is worth doing. +20:45:45 K_F: jlec: the transition is pretty much a conditional dependency +20:45:55 monsieurp: blueness: libressl shouldn't be one-man job anyway, like it used to be before, but a project +20:46:12 monsieurp: blueness: i know you wont walk away from gentoo but look at the situation right now  +20:46:14 rich0: But, start with forming a team. Like anything around here it will end up living or dying based on interest. +20:46:16 K_F: jlec: since all packages needs to be switched at the same time +20:46:21 blueness: K_F: let me put it thsi way, i have entire desktops running libressl +20:46:24 blueness: jlec: each package needs a few lines add to the DEPEND +20:46:25 blueness: jlec: look at the very top of https://github.com/gentoo/libressl/wiki/Transition-plan +20:46:26 blueness: under Fixing unstable arch ebuilds +20:46:38 blueness: if i can get individual devs to do that to their package then it would really lower the barrier +20:46:46 jlec: blueness: but why this is a problem? Just the workload? +20:47:01 blueness: jlec: yes +20:47:09 blueness: its easy but many many ebuilds +20:47:14 WilliamH: blueness: just start filing bugs against the packages. +20:47:14 jlec: so we need a project team and ask people to join +20:47:17 K_F: I wouldn't be comfortable with people switching crypto library in packages they don't maintain +20:47:25 blueness: WilliamH: even that is a lot of work +20:47:36 K_F: so again, tracker bug with filing for individual packages seems to be the way to go for that part +20:47:46 blueness: K_F: hasufell was doing that way before i was +20:48:13 K_F: blueness: he didn't touch the packages I maintain, but it does break protocol +20:48:15 blueness: K_F: that’s a tremendous amount of work for one person +20:48:35 dilfridge: K_F: usually he filed bugs / asked people +20:48:36 WilliamH: K_F: he did touch a couple I work on, and yes it does break policy. +20:48:41 K_F: dilfridge: exactly, which is fine +20:49:08 WilliamH: dilfridge: he didn't contact me, and he did rev bumps on packages I maintain. +20:49:13 K_F: https://devmanual.gentoo.org//ebuild-maintenance/index.html +20:49:17 K_F: Touching other developers ebuilds +20:49:28 K_F: to have a reference tot he policy +20:49:29 jlec: *doesn't feel able to really judge any crypto library usage.* +20:49:31 blueness: the point of bringing this to the council is that protocol is overwhelming here, +20:50:07 blueness: K_F: whos’ going to do the work of removing libressl from the tree if we do? or do we just leave the cruft behind +20:50:13 rich0: As long as there is a transition plan and a project and the project members are responsible to bugs they create, I don't mind having them modify ebuilds to add libressl support to them. But, they have to be responsible to address issues. +20:50:17 blueness: because there’s about as many packages with libressl as there is without +20:50:33 dilfridge: how about "we encourage devs to test and add the flag/conditional deps, and coordinate with the libressl team, to be formed" +20:50:36 rich0: And of course they should try to work with maintainers as much as is reasonable. +20:50:37 WilliamH: blueness: you can post a msg to -dev and give notice that way maybe... +20:50:41 monsieurp: dilfridge: YES! +20:50:44 blueness: dilfridge: thanks +20:50:45 K_F: rich0: my take on that would be that a council decision should be made in that case +20:50:54 K_F: rich0: to allow libressl into tree globally +20:50:57 blueness: dilfridge: that works +20:51:30 rich0: I'm not approsed to having a council decision - but in general I don't have a problem with projects doing their thing as long as they have a plan, communicate, and follow-through. +20:51:47 K_F: rich0: we're talking about security critical changes here +20:51:48 ulm: dilfridge: the council says that a project should be formed? that seems strange +20:52:02 rich0: So, perhaps for the next meeting we should set a goal of having a libressl project live, and have a specific proposal for the council to approve? +20:52:05 blueness: K_F: i trust the openbsd people way before the openssl people +20:52:22 WilliamH: ulm: we aren't really giving a directive that a project should be formed... +20:52:51 WilliamH: ulm: anyone can start a project whenever. +20:52:51 dilfridge: I mean more "there is already intention to form a project" +20:52:53 K_F: blueness: that is a separate point from whether a council decission is needed before it is applied directly by a newly formed project +20:53:07 ulm: I'd rather see the project being formed by any interested parties, and then that project should bring issues forward to the council +20:53:15 rich0: Nobody needs council approval to form a libressl project - just do it! +20:53:16 blueness: i’m still not sure why a project is needed though +20:53:16 jlec: a) The council ask for the formation of an official libressl project which will be the future contact on the libressl introduction. b) The council encourages all developers to test and add the flag/conditional deps (https://github.com/gentoo/libressl/wiki/Transition-plan#fixing-unstable-arch-ebuilds) for libressl support. +20:53:22 jlec: How about that? +20:53:22 WilliamH: *thinks the only council decision really would happen if* +20:53:22 rich0: ulm: ++ +20:53:27 rich0: step 1 - make a project +20:53:29 WilliamH: we were removing openssl +20:53:34 rich0: step 2 - make a reasonable plan/proposal/etc +20:53:39 rich0: step 3 - put it on the agenda  +20:53:53 dilfridge: suggestion +20:53:57 jlec: good idea +20:53:58 ulm: rich0: ++ +20:54:01 WilliamH: Do we have to bless every alternative that comes along? +20:54:09 WilliamH: unless it is trying to become the default? +20:54:12 dilfridge: blueness: create the libressl project NOW, and we can say it exists. +20:54:17 blueness: WilliamH: that totally misses the point here +20:54:27 blueness: one sec, consider this +20:54:29 dilfridge: (how long does it take to make a wiki page?) +20:54:30 K_F: WilliamH: we do if external participants want to touch other maintainer's ebuilds +20:54:31 blueness: nothing gets done +20:54:48 blueness: 1/2 the packages in the tree that consume openssl now consume both +20:54:51 blueness: 1/2 don’t +20:54:56 blueness: do we just leave it that way? +20:55:06 dilfridge: it's kinda pointless +20:55:23 rich0: blueness: we leave it that way for now until somebody comes up with a plan to change it or it is clear that it isn't going anywhere +20:55:29 ulm: blueness: if there's interest then there will be a project with > 1 dev +20:55:41 jlec: How about the following? +20:55:42 jlec: The council ask for the formation of an official libressl project which will be the future contact on the libressl introduction. The project should present a plan regarding finishing of the libressl introduction to Gentoo. +20:55:43 ulm: if not then maybe it's better to remove it +20:56:07 WilliamH: jlec: we don't need to do that. +20:56:09 K_F: ulm++ +20:56:13 rich0: jlec: I'd frame it more as "the council suggests..." or soemthing like that +20:56:18 rich0: And we don't need to vote. +20:56:21 blueness: ulm: there were a large number of contributors +20:56:24 WilliamH: jlec: nothing is stopping blueness from forming the project right now. +20:56:24 rich0: We're already doing just that. +20:56:37 jlec: okay perfect +20:56:42 ulm: blueness: good, then there's a good chance that it will fly +20:56:43 rich0: Ultimately "be bold" as they say on wikipedia +20:56:55 jlec: than we postpone anything alse on this topic until we have a project +20:57:07 rich0: Form an army - and charge the gates of the council demanding change.  +20:57:14 blueness: i’m debating whether or not to just leave the mess then, this is really not help +20:57:18 dilfridge: Uruk-hai! +20:57:23 jlec: Should we move on? +20:57:30 K_F: jlec: yup.. +20:57:32 jlec: 3) Automatic bug assignments [3] +[3]https://archives.gentoo.org/gentoo-project/message/00e02ff494857599633e2bbc30520ca3 +20:57:35 WilliamH: blueness: talk up the project; get devs involved.  +20:58:15 WilliamH: *just saw we are moving on sorry folks* +20:58:46 dilfridge: about 3)... from my numbers, I see no obvious problem at the moment, bug-wranglers seem to be getting on OK. +20:59:06 dilfridge: does anyone know more why this comes up now? +20:59:32 rich0: I think not having auto-assignment is silly. If somebody wants to implement it, I'm all for it. Bug wranglers can still review new bugs after they're auto-assigned, or have a waiting period, or whatever. +20:59:42 rich0: But, this isn't a burning platform. +20:59:50 rich0: It comes up every few years it seems. +21:00:19 K_F: my thoughts are (i) there should be a delay, as I expect some users changing summary directly after posting (ii) it might be easier to implement as a bot querying bugzilla than directly in the platform +21:00:20 jlec: it does, but in general the assignment just goes fine +21:01:00 K_F: but indeed, i tend to agree that automating things is generally an improvement, and leaving up manual work to cleaning things up afterwards might take less resources +21:01:23 monsieurp: about 3) I responsed to this thread with a detailed answer: https://archives.gentoo.org/gentoo-dev/message/1dd4685dfaaae9d96c18022507f2afb9 +21:01:57 dilfridge: gentlemen while normally I have lots of time today I have to leave +21:02:21 monsieurp: tl;dr: already implemented by the FreeBSD project with their Bugzilla (https://bugs.freebsd.org/); Bugzilla extensions can be found here: https://github.com/freebsd/bugzilla/tree/freebsd-local/extensions/FBSDAutoAssign +21:03:17 K_F: however, I would prefer to see a statement from bug-wranglers on this +21:03:51 K_F: and nothing is stopping them from automating things within the project +21:04:02 rich0: K_F: bug wranglers have spoken up on stuff like this before. They like fixing broken summaries, culling dups, etc. The work still gets done, so nothing to see here... +21:04:09 K_F: so I doubt council decision is needed if they want to automate things +21:04:25 K_F: rich0: exactly, then nothing for us to do +21:04:33 K_F: they are doing a good job already +21:04:45 rich0: Personally I find non-automation a PITA. I feel bad about just dropping bugs on the bug-wranglers, so I manually go looking up metadata to make sure I assign stuff right +21:05:06 K_F: rich0: ditto, but then things works as it should to some extent +21:05:11 rich0: In any case, if somebody wants to step up and automate things, I'll be happy to approve it +21:05:24 rich0: But, I'm not sure we actually have anybody stepping up, so this whole issue seems a bit moot. +21:05:28 WilliamH: K_F brought up an interesting point. +21:05:39 rich0: I'll probably just start assigning more bugs to bug-wranglers... +21:05:41 K_F: rich0: if it is done within the scope of bug-wrangslers I'm unsure whethern approval is needed +21:05:44 WilliamH: This is a bug-wranglers issue, so do we even need to be involved? +21:05:46 jlec: I think, the council shouldn't decide anything. It's up to the bug-wranglers if they like ot have something like this. And if, they should start working with infra to implement it +21:05:59 rich0: K_F: I imagine this would only happen over active protest of the wranglers +21:06:08 ulm: I agree that this is bug-wranglers territory so they should decide on it +21:06:25 jlec: okay, so let's move on +21:06:27 jlec: 4) The usage of use() in global scope violates PMS [4] +21:06:31 rich0: In any case, I'm not volunteering to automate things, so until somebody else is it is a bit of a moot point +21:06:40 jlec: [4] https://archives.gentoo.org/gentoo-project/message/69ed522b3b53de90e616267a77441012 +21:06:44 rich0: jlec: burn with fire... +21:06:56 K_F: yup, lets formally block that +21:06:56 ulm: policy is clear on this one +21:07:07 dilfridge: I guess my opinion on that is pretty well known by now. +21:07:20 blueness: mgorny: are you there? +21:07:31 blueness: so is this just about the multislot in toolchain.eclass? +21:07:34 mgorny: yes +21:07:46 blueness: is that the last point of resistence? +21:07:50 dilfridge: so maybe we can decide on some definite action? (not just it's not allowed, but this-and-that-will-be-done?) +21:08:01 mgorny: yeah, toolchain and toolchain-binutils, i think +21:08:27 blueness: mgorny: if so then let’s not make a policy to cover everything when its just the toolchain eclasses +21:08:41 blueness: we as a council email vapier and say … this is the issue +21:08:44 dilfridge: we dont need any new policy +21:08:55 dilfridge: we have one and it covers this +21:08:57 ulm: PMS reference is here: https://projects.gentoo.org/pms/6/pms.html#x1-650007.1 +21:08:58 blueness: the argument is sound, use in the global scope breaks metadata +21:09:24 blueness: ask him to fix within a reasonable amount of time else we will (or i will) +21:09:39 blueness: dilfridge and i looked that over and its just about allowing the microversions of gcc +21:09:45 WilliamH: Is 30 days a reasonable amount of time? +21:09:55 blueness: that can be done on an overlay since its just for debugging purposes +21:10:08 K_F: blueness++ +21:10:14 blueness: gcc is very good on bumping Z in X.Y.Z for *just* bug fixes +21:10:17 WilliamH: blueness ++ +21:10:24 dilfridge: I know only for gcc +21:10:34 dilfridge: but there I'm perfectly fine with that plan +21:10:37 dilfridge: 30days +21:10:39 ulm: binutils too I think +21:10:48 blueness: yeah i thing so +21:10:57 blueness: i don’t want to send that email though +21:11:05 blueness:  +21:11:15 K_F: ok, we likely want a formal decision on this one +21:11:20 WilliamH: or do we want 14 days? +21:11:22 K_F: to back up any action +21:11:25 blueness: no 30 days +21:11:25 dilfridge: 30days is fine +21:11:29 K_F: WilliamH: 30d is fine +21:11:32 blueness: its been broken for years +21:11:53 K_F: but in the process, should we make a decision on dymanic use flag determined SLOTS? +21:12:03 K_F: which is keeping that as blocker +21:12:07 blueness: i get why its there and i actually like it, or dynamic slots, but if its a QA issue we cna live without it +21:12:10 K_F: if we disallow that due to PMS violation +21:12:12 dilfridge: K_F: we dont have to; that is banned, forbidden +21:12:17 dilfridge: for ages already +21:12:24 ulm: K_F: https://bugs.gentoo.org/show_bug.cgi?id=174407#c4 summarises it nicely +21:12:27 K_F: dilfridge: yet the request is still open and used as an argument +21:12:31 blueness: K_F: that’s the only thing i disagree with, i like dynamic slots so lets defer that +21:12:45 WilliamH: blueness: dynamic slots can't happen +21:12:46 jlec: How about this: +21:12:48 jlec: The council request all global usage of use() violating PMS (https://projects.gentoo.org/pms/6/pms.html#x1-650007.1) to be fixed util the March 2016 council meeting. After that members of the QA are asked to fix remaining ebuilds/eclasses. +21:13:02 jlec: For the use() issue +21:13:27 K_F: jlec: sounds good to me +21:13:30 blueness: that’ sounds fine +21:13:35 ulm: +1 +21:13:40 jlec: Vote: The council request all global usage of use() violating PMS (https://projects.gentoo.org/pms/6/pms.html#x1-650007.1) to be fixed util the March 2016 council meeting. After that members of the QA are asked to fix remaining ebuilds/eclasses. +21:13:40 WilliamH: +1 +21:13:43 K_F: *yes* +21:13:47 jlec: *yes* +21:13:49 blueness: *yes* +21:13:56 ulm: *yes* +21:13:59 WilliamH: *yes* +21:14:23 jlec: dilfridge: still there? +21:14:25 dilfridge: *yes* +21:14:31 dilfridge: (quasselclient crashed) +21:14:34 jlec: passed. all yes +21:14:44 jlec: So how about dynamic slots now? +21:14:54 K_F: jlec: its not on agenda, deferr +21:15:00 dilfridge: *has to leave, see you* +21:15:04 K_F: dilfridge: bye +21:15:28 jlec: K_F: it is in the mail of mgorny +21:15:51 K_F: jlec: only because it is used as an argument against what we have already decided on anyways +21:15:54 jlec: Anyways, now that we requested the removal, we cannot have dynamic slots ever +21:16:06 K_F: the question whether it could potentially be implemented ever is another topic +21:16:23 blueness: no we should defer that +21:16:24 blueness: i’m not yet convinced that they can’t happen as WilliamH suggests +21:16:27 WilliamH: I think dynamic slots can't happen because of metadata +21:16:43 jlec: That's what I mean +21:16:45 blueness: WilliamH: there may be other ways of designing it +21:16:48 ulm: dynamic SLOT is comparable to dynamic PN +21:17:09 ulm: and IMHO both don't make much sense +21:17:16 K_F: it seems difficult to do, but lets defer, there might be ways of doing it I haven't thought of atm +21:17:17 blueness: i know about metadata but again, there may be something that can be done, i haven’t thought it through carefully +21:17:18 WilliamH: ulm: +1 +21:17:38 K_F: so that will have to be discussed on its own merits +21:17:41 blueness: ulm: dynamic slots do make sense +21:18:00 blueness: i can give examples, but whether they cause problems with metadata is another issue +21:18:11 ulm: blueness: not controlled by USE flags though +21:18:20 blueness: ulm: maybe yeah +21:18:38 K_F: ulm: that seems likely, indeed +21:18:41 blueness: but they do make sense for gcc because you can install 4.8.1 and 4.8.2 etc side by side +21:18:53 blueness: the question is one of what granularity do you want +21:19:00 K_F: blueness: you can do that already similar to kernel sources +21:19:09 K_F: without dynamic deps +21:19:26 WilliamH: You would just have SLOT="" +21:19:27 blueness: K_F: no it causes problems with gcc +21:19:32 K_F: so the question seem more a question whether we can introduce a class of slot that allows micro version when requested but only major by default +21:19:54 K_F: i.e PMs ignoring the last part of a slot assignment unless configured +21:19:57 blueness: because you if you don’t have multislot and you have 4.8.3 and 4.9.3 installed and 4.8 is bumped to 4.8.4 you want 4.8.3 gone +21:19:57 K_F: irrespective of USE +21:20:02 blueness: but not 4.9.3 +21:20:09 K_F: so a "significance" indicator +21:20:11 blueness: that’s not how the kernel works +21:20:26 K_F: blueness: that is due to SLOT being 4.8 +21:20:29 WilliamH: blueness: doesn't it just have SLOT="" +21:20:52 ulm: we won't solve a problem which is being discussed since a decade during this meeting, so can we move on please? +21:20:53 WilliamH: blueness: s/it/the kernel/ +21:20:57 ulm: *has to leave soon* +21:21:09 blueness: i agree +21:21:12 blueness: its an aside +21:21:19 K_F: but lets discuss that later, no action needed from us +21:21:20 jlec: So let's defer and have the discussion next time +21:21:34 K_F: blueness: catch me after meeting, and we can discuss a possible solution  +21:21:40 jlec: 5) Bugs with council involvement [5] +21:21:46 jlec: [5] https://bugs.gentoo.org/buglist.cgi?email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3067702&query_format=advanced&resolution=--- +21:22:25 jlec: https://bugs.gentoo.org/show_bug.cgi?id=566498 +21:22:48 K_F: nothing for us to do +21:22:54 jlec: What should we do here? Set a deadline? +21:23:31 ulm: jlec: that won't help as it's too many packages +21:23:39 jlec: so let's leave it then +21:24:04 WilliamH: That bug just needs people to do the work. +21:24:10 ulm: mgorny has added a deprecation notic to the eclass +21:24:15 ulm: *notice +21:24:26 ulm: and I think that's about what can be done for now +21:24:31 K_F: ulm: yup +21:24:55 jlec: https://bugs.gentoo.org/show_bug.cgi?id=568068 Any progress on the GLEP? +21:25:21 ulm: the question is if to include a Display-If-Visible header +21:25:33 ulm: otherwise it's straight forward +21:25:48 ulm: I'll try to come up with something for the next meeting +21:25:55 jlec: perfect thanks +21:25:59 K_F: sounds good +21:26:08 jlec: https://bugs.gentoo.org/show_bug.cgi?id=569914 +21:26:24 jlec: the ever reoccurring topic +21:26:34 jlec: dilfridge ^^^ +21:26:43 K_F: will just have to be fixed in due course, at least the log is there +21:26:47 K_F: nothing for us to do +21:27:01 jlec: https://bugs.gentoo.org/show_bug.cgi?id=574080 again games.eclass +21:27:08 jlec: nothing we ca do right now +21:27:17 jlec: 6) Open floor +21:27:18 K_F: seconded +21:27:32 jlec: Community, anything you like to have discussed? +21:28:43 blueness: nothing from me +21:29:22 jlec: Alright, let's close it then. +21:29:27 K_F: jlec: thanks for chairing +21:29:28 jlec: *bangs the gavel * +21:29:33 jlec: Thanks for the meeting +21:29:52 rich0: thanks |