time to start [19:54] agenda at https://archives.gentoo.org/gentoo-dev-announce/message/106bd518b11a2e9700e7d77606cb7c23 [19:55] dilfridge: dilfridge|mobile jlec K_F rich0 ulm WilliamH wierd my computer says 4 minutes to the hour but my computers says 4 minutes after! [19:56] Sounds like you need to configure NTP on some of your computers. [19:57] * WilliamH is here, my clock is at 18:57 utc floppym: i do have ntp Same here there’s one central ntp server i think my one computer is off and everything is syncing off of it well it doesn’t hurt to wake people up a bit early [19:58] blueness: heh here [20:00] here Here * jlec here * WilliamH here [20:01] rich0: I'm proxying for ulm. ulm: is probably not going to show up oh okay floppym the agenda is here https://archives.gentoo.org/gentoo-dev-announce/message/106bd518b11a2e9700e7d77606cb7c23 so the first item is to look at the updates to glep 42 on news items [20:02] https://archives.gentoo.org/gentoo-dev/message/b9460b9c8d578c3498c217c17b75afd4 ulm also has a prepared update to the glep page at https://wiki.gentoo.org/wiki/User:Ulm/GLEP:42 [20:03] take a sec to look it over and then let’s discuss Hvae read through it and the changes seems to be in line with what we have previously discussed, including some more definition on backwards vs forwards compatible tool vs file format.. [20:04] I cannot spot anything wrong [20:05] Lgtm you can search for format 2.0 in the proposed wiki page which nicely specifies the new featurs I do find it strange that we still cater to 80 column terminals, but 50 is certainly better than 44. i agree i can’t see anything wrong The changes look reasonable to me. [20:06] floppym: I rarely use more than 80 cols personally lgtm Please no 80 char discussion floppym: for git on gitweb 72+ chars is a problem Ah. so there are still places where the are problems I was just making a comment; no real objection here. lol jlec okay * dilfridge bites the ears off a chocolate bunny heh [20:07] are we ready for a vote then? Yes okay “Accept proposed changes to GLEP 42”? * blueness yes * WilliamH yes * dilfridge yes I vote yes, to accept the changes. * K_F yes * jlec yes [20:08] unanimous with one missing rich0 wow that was easy okay next item 3. Historical behaviour vs PMS (see above) ok one remark from me [20:09] as a point of order I suggest we don't have any decisions /votes today, but a discussion ulm: thanks for your work on glep 42 I suggest that in any case improving PMS should be also considered as option. (Not just adapting code to current PMS.) dilfridge: certainly, improving PMS might very well be an outcome of mismatches [20:10] yeah, this is not clear from the text that I submitted. Which mismatches are we specifically talking about? All of them. :) the important thing is that the specs and reality matches, which one is out of sync will have to be discussed case by case dilfridge regarding point 3? well... [20:11] when we're talking about time frames, If we are talking about the multislot uselfag issue, kill it hard ;-) and deadlines, I would rather have a shorter deadline (say 6 months) with the proviso that anything planned to go into next EAPI is exempt [20:12] The slot variable should be a static string not dependent on a use flag. WilliamH: totally agree with you in that point can i suggest something, i think those points are too harsh, i’d like to track the mismatches between specs and package managers, but then deal with each mismatch on an ad hoc basis, because we can change PMS too we don’t want to throw out the baby with the bath wather water WilliamH: yeah, that one is likely the easiest to decide on blueness: exactly [20:13] I'm really not sure how a deadline could be applied generally. would need to be a case by case basis ok so let me try to re-write the three points It really depends on the nature of the mismatch and the people involved. if we find a mismatch, we may want to include the undocumented behavior in PMS rather than vice versa so it has to be ad hoc 1) All non-PMS-conformant behaviour should be considered a bug, and package / eclass / package manager / PMS maintainers should work together and to achieve consistent behaviour. [20:14] If there is take me to solution then things are easy in case there's none we will have a problem *technical s/and to/and strive to/ dilfridge: should it be specified .. bug (either in specs or implementation) [20:15] to avoid ambiguity? well, I left it open deliberately i don't think we can put a generic rule for this discouraging use of non-PMS compliant behavior if people don't even try to get it into PMS would be good though [20:16] mgorny: well that is just a general point, and in principle it is sound.. just that we need to go through case by case basis to see whether PMS needs updating or the behavior does.. i'd say for each behavior, there are three possibilities: 2) We encourage the creation of trackers to identify and collect non-PMS-conformant behaviour and propose fixes. a. bad behavior, we deprecate and kill it; b. good behavior, we get it into future EAPI and encourage updating ebuilds, c. intended behavior, we get it into all EAPIs [20:17] yep mgorny: there is yet a fourth, an ambiguity in PMS specs which happens enough and also leads to discussion But that sounds like b [20:18] well, either a or b depending on situation :) I was optimistic [20:19] i’m not sure they’re mutually exclusive, but we get different behaviours between paludis, portage, pkgcore and PMS specs That's a different thing. Ebuilds and eclasses should only depend on pms [20:20] because each will read PMS differently, we had that with =cat/pkg-2.* vs =cat/pkg-2* agreed That's what this is all about are we talking just ebuids/eclasses here? blueness: if there are other known issues I suggest we include them in scope [20:21] What else? blueness: but the specific ones that have already been brought up are ebuilds/eclass related if we’re just talking multislot that’s pretty much gone Aren't we just talking about compliance with pms? WilliamH: or PMS matching reality [20:22] 3) The council recognizes that historically there has been a lack of cooperation; there is however no current reason why that should continue. If in any specific issue no progress at all is reached within 6 months, finding the best technical solution is delegated to QA. dilfridge: finding the solution is delegated meaning they propose a solution for council vote or implement it directly? [20:23] well, pms changes need to be approved by council ebuild changes need to be approved by maintainer qa can overrule maintainer but likely not council [20:24] yes, strictly speaking qa can override maintainer per the current rules and the maintainer can appeal to the council if he disagrees dilfridge let me understand the politics here, are we just trying to make a policy cover future situations like multislot? [20:25] blueness: we're trying to get rid of a historical stalemate blueness: and/or investigate whether other mismatches exists As a member of qa I would mask the multislot use flag right now if I felt comfortable doing it ;-) and indeed, setting a presedence for how to deal with it going forwards if one is detected (it is bound to in some way) [20:26] Masking the use flag is in the scope of qa as the rules are right now. WilliamH: Masking the use flag would not be helpful if use is fatal in global scope. blueness: basically, half of gentoo treating PMS as "the spec" and some of gentoo treating PMS as "that funny stuff imposed on us by ciaranm" so, to break out of this we need to 1) make sure reality and PMS agree, 2) make sure that it really is the definitive spec [20:27] once you're done with the generic problem, we should probably decide how to proceed with multislot mgorny: I already have a headache. [20:28] my suggestion is no decision on single issue today just mask it(tm) dilfridge: thanks i misunderstood where this was coming from. i don’t mind the specs lagging behind the package managers and ebuilds/eclasses, so let’s just say that bugs have to be opened where the specs don’t match either and these have to be dealt with in a timely fashion else it escalates to QA first and then the council each individual issue should be presented on a case-by case basis and discussed with pros and cons on ML before a vote K_F: that sounds reasonable. I do think we should open a tracker too though for the issues. [20:29] WilliamH: yeah, and/or tracker I like the idea of a documented escalation process for these kind of issues; though I thouht we already had that. floppym: I think we basically do. [20:30] floppym: we have that its like anything else we’re not voting today, are we? [20:31] I don't think we are blueness: we can vote on procedure but I recommend not voting on a single issue no single issues ah okay, dilfridge can we consolidate your 3 points into one statement, I can suggest something if you like [20:32] one moment dilfridge: take your time, i’ll wait for you wrt multislot, I have a better idea. [20:34] well, here's the combined text with only one small change (s/finding/proposing/): WilliamH: if we set up a discussion for it we can take it in tracker / ML perhaps? All non-PMS-conformant behaviour should be considered a bug, and package / eclass / package manager / PMS maintainers should work together and to achieve consistent behaviour. We encourage the creation of trackers to identify and collect non-PMS-conformant behaviour and propose fixes. The council recognizes that historically there has been a lack of cooperation; there is however no current reason why that should continue. If in any specific issue no progress at all is reached within 6 months, proposing the best technical solution is delegated to QA. WilliamH: please talk about multislot separately [20:35] mgorny: ok dilfridge: s/and to/in order to/ perhaps? dilfridge: that sounds fine, how do we promulgate that? email gentoo-dev@g.o ? K_F: where? blueness: just send it to -dev and maybe -project? [20:36] WilliamH: 1 sec, let’s get this language out of the way? dilfridge: "should work together and to achieve consistent behaviour." blueness: sure K_F: s/and to/to/ that also works.. how do people feel about this? are we ready for a vote module the minor lanuage chagnes? [20:37] wait new version: k ll non-PMS-conformant behaviour should be considered a bug, and package / eclass / package manager / PMS [20:38] maintainers should work together and strive to achieve consistent behaviour. We encourage the creation of trackers to identify and collect non-PMS-conformant behaviour and to propose fixes. The council recognizes that historically there has been a lack of cooperation; there is however no current reason why that should continue. If in any specific issue no progress at all is reached within 6 months, proposing the best technical solution is delegated to QA. 6 month means busy summer. I are we sure the time frame is good? (insert "A" at start) So the guts of this is the 6 month deadline. The rest is just reaffirmation of pretty obvious stuff. jlec: 6 months should be sufficient even with summer involved jlec: that is also just a deadlock limit, if there is progress it doesn't hit Mmh, okay [20:39] if people are acting in good faith, we can consider relaxing 6 months for thorny issues Lgtm I'm fine with that statement i’m okay with the 6 month limit [20:40] are we ready for a vote, any other comments? I'm ready for vote [20:41] * jlec yes okay “The council moves to adopt the above policy”? * blueness yes * dilfridge yes * WilliamH yes [20:42] * K_F yes * jlec yss I abstain. passes, 5 yeses, 1 abstain, 1 missing rich0: are you around? okay do we want to discussion multislot now? Here's my thought. [20:43] that is just one of the other single issues, so it should be discussed in tracker bug for it and/or ML Let me open bugs on the issue assigned to maintainers and cc qa/council. go ahead, its slightl off agenda, but we have some time and we’ll have to discuss it sooner or later I'll ask the maintainers to remove the use flag. and add that if they do not qa / council has authorized its removal in 30 days. [20:44] that would require a vote errr but we already have a decision wrt multislot and the discussion afaik long ago already there was a qa decision about multislot open the bug as part of tracker for the overall discussion [20:45] hang on folks let me pull up something just noone pushed it through so far last month council decided today's deadline for maintainers applying it mgorny: i haven’t looked but didn’t vapier remove multislot from toolchain.eclass? right :D blueness: nah but he proposed a patch never mind, just looked, its still there ah that’s what it was [20:46] so i wanted to suggest we just apply it or talk to him about applying it blueness: binutils was changed blueness: you seemed to be against it K_F: what they are doing violates this: https://devmanual.gentoo.org/general-concepts/portage-cache/index.html or did i understand your comment wrong? mgorny: not exactly gainst it, i was thinking a different approache he’s going to just turn multislot on always, i wanted it off always WilliamH: I'm aware.. there are still good ways and bad ways of enforcing it [20:47] but i can live with his solution WilliamH: and it has been around for so long, another few weeks isn't going to kill anyone, at least do it in a civil manner * mgorny actually uses multislot, so on always sounds better to me I don't have a problem with it being on or off for everyone, just make a decision either way ;-) It's really up to toolchain how they want to slot it. mgorny: like i said, i can live with it on always blueness: can you handle this as toolchain member? [20:48] mgorny: i could but i alway defer to vapier The issue is that SLOT= can't be dynamic. let’s see if he’s just not going to do it, and if he isn’t then i’ll step in like i did with glibc WilliamH: I think we are all on the same page on the technical side. All I'm asking for is for them to make up their mind ;-) [20:49] Guys, we don't need to discuss this. It needs to go and we know it. ++ blueness: could you then talk to him? i think he just needs a reminder/push/whatever either they do it in a reasonable amount of time or qa does it then they fix it without the use flag. :-) [20:50] * WilliamH agrees with mgorny mgorny: i can What's left on the agenda? okay guys, i think enough discussion on multislot, i’ll email vapier and say, let’s get it done! okay guys, i think we’re done here last item [20:51] Bugs with council involvement https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3101194&query_format=advanced * ulm is here floppym: just go on, I'm reading the backlog ulm: welcome! [20:52] Don't kick him out He really did a good job I don't understand why council is involved in #575534 okay 575534 is wierd [20:53] lol! K_F: jinx okay let me take care of that one right now missing logs in two bugs, who chaired? [20:54] i’m going to ask that a3li and mgorny work it out between themselves before escaating For what its worth, I hate it when I get a degraded experience on mobile too. It's very annoying. (speaking generally, not just about our wiki) [20:55] * mgorny has done enough random gentoo project and certainly isn't going to patch this nonsense dilfridge: seems both are yours :) :/ meh and a3li is pretty much 'mgorny does not like it, so i'm going to ignore this' *** viaCrucis (~scott@91.33.233.220.static.exetel.com.au) has joined channel #gentoo-council * WilliamH isn't sure why that was assigned to council WilliamH: it shouldn't have been [20:56] There's not a lot we can do there. mgorny: QA can mask the package if its bad enough! Is that a bad joke? Mask the wiki? [20:57] * floppym masks bluness' sens of humor floppym: yes it is well, the council is the entity which decides that wiki is the official doc channel mgorny: yes, but we didn't mandate anything about which wiki software to use etc. [20:58] or triaging of bugs within infra what about bug #574952 mgorny what would you like us to do with that since games + QA have been at it for a while blueness: https://bugs.gentoo.org/574952 "Games team intentionally ignoring messages and bugs in order to stall QA and Council"; Community Relations, Developer Relations; CONF; mgorny:comrel this is a regular bug report like any other yes, www stuff is pretty much a3li deciding whatever he wants by himself and with no respect to other developers similarly bug #574080 [20:59] blueness: https://bugs.gentoo.org/574080 "games.eclass: Path customization needs to be removed wrt 20151213 Council meeting"; Gentoo Linux, Eclasses and Profiles; CONF; mgorny:games blueness: that's comrel problem, i'd say yeah council CC-ed because it was involved and may want to track events and/or be inquired mgorny: I think we can't really force a3li to implement something, but if you find someone else who can do the work we can stop him from blocking it if necessary. [21:00] wtf?! I said I accept your issue the a3li might escalate there, but let’s see i agree with trakcing the games stuff since its a big issue floppym: i was going to suggest something like that someone to supply a patch also, what's with the borderline slanderous comments mgorny is allowed to make her?!° a3li: i don’t like those comments either but can you and mgorny just stick to the technical issues wrt to that pkg [21:01] that's very hard when I get shit shoveled at me at any occasion, you know a3li: i understand. so just take a break from it and don’t think you’re isolated here. [21:02] I'm not. I think someone else isolates himself with inane commentary atm. [21:03] in any case, I don't see any more for council to do with open bugs so propose we close today's meeting [21:05] mgorny: still not sure how to proceed with the games stuff there are 3 bugs there with council involvement a3li: and yeah, I didn't like those comments either.. K_F: open floor i have one quick announcement well, the eclass is deprecated, i thnk games team doesn't bother replying on the topic okay well continue with the stalement? [21:06] Then have QA set a deadline and remove it with all usages [21:07] I guess all the deadlines are over anyway and it just needs someone to do the actual work. yeah right, maybe best if qa takes care of the technical issues [21:08] well, i wouldn't feel good rewritting packages maintained by games team for this mgorny: i’m going to bounce this back to QA to decide what do to esp. that they didn't really approve any of it ulm: +1 and avoid filing bugs with "games team intentionally ignoring ..." in the summary that's not going to lead anywhere ulm: +1 again, they’re just not listening * WilliamH agrees blueness: I wouldn't outright listen to such statements either, tend to get the deaf ear.. [21:09] so yeah, keep the bug reports factual and neutral in nature agreed [21:10] in particular if involving council... you could complain if they didn't admit it mgorny: maybe QA can create an overlay and move all the deprecated stuff there and then put the onus on games to move it back into the tree in a compliant fashion … i know, its work! mgorny: ^^^ as K_F said, please try to avoid the ad hominems QA needs to be a policy force and at least appear neutral okay let’s move on, i don’t want to get mired in this [21:11] final point i’ll comment on bug #568068 our decision today blueness: https://bugs.gentoo.org/568068 "GLEP 42: Define support for EAPI 5 dependency atoms in news items"; Doc Other, GLEP Changes; IN_P; floppym:glep anything else before opne floor okay open floor [21:12] i have one annoucnement last council meeting we spoke about hasufell’s pkgs and work There already is a graveyard overlay I think; I don't know who maintains it. sorry go ahead blueness i’ve started a libressl project and we have dilfridge soap and zn2x (forget his nick!) on board [21:13] I expect that to be zx2c4 r2d2 K_F: ty! Any long-term goal for that project? Are you aiming to replace openssl, or just provide a perpetual alternative? [21:14] anyhow, we’ll have a plan for moving forward and we’ll at least inform the council floppym: the basic goal is two provide two system wide alternatives either you have an all libressl system or all openssl openssl will not be replaced in any way, just a permanent alternative [21:15] Ok. That's the safer route for sure; I was kind of hoping for a more entertaining conflict. :P two steps 1) getting it into the tree 2) provide support to maintainers who have packages that depend on openssl so we offset any extra work regarding abi mismatches floppym: lol no! floppym: i think openssl has actually benefited from libressl just being an alternative [21:16] anyhow, we’ll meet and report back blueness: sounds good Competition tends to spur innovation, yes. nothing else for now, just FYI floppym: that’s the idea! okay if theres nothign more we’re done! [21:17] thanks for chairing np oh crap … ulm are you there? did you log this? can anyone send me the logs? floppym: thanks for proxying anyhow meeting over [21:18]