path: root/meeting-logs/20160214.txt

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