[20:59:24] ping dilfridge dilfridge|mobile jlec K_F ulm WilliamH [20:59:30] -*- K_F is here [21:01:15] there really is no agenda for today, no one submitted any issues [21:01:28] so we can go directly to open bugs and open floor [21:02:02] should likely do a roll-call just for the sake of it [21:02:41] -*- dilfridge here [21:03:12] K_F: of course, we're doing that now [21:03:21] so far only 3 [21:03:29] rich0 mentioned he likely would be unavailable [21:04:01] we'll need to have new elections if we don't meet the quorum :/ [21:04:06] but we do [21:04:08] -*- ulm here [21:04:22] ehm [21:04:30] we have new elections anyway [21:04:31] ping jlec WilliamH [21:04:39] ulm: :) [21:04:43] oh i missed rich0 ping [21:04:59] dilfridge: yeah, that was the joke :) [21:05:08] :P [21:06:52] okay proceed with just dilfridge ulm K_F [21:07:07] dilfridge: can you email me the log afterwards like last time? [21:07:20] blueness: sure [21:08:03] okay there are no agenda iteams, so let's proceed directly to open bugs [21:08:24] i see only one bug with council@ cc-ed [21:08:36] there is also bug 618930 for the records [21:08:38] K_F: https://bugs.gentoo.org/618930 "Council confirmation for May 2017 QA lead election"; Gentoo Council, unspecified; RESO, FIXE; ulm:council [21:08:43] bug #618254 [21:08:48] "That's a confirmation with 5 yes votes and 2 abstentions. Congrats!" [21:09:11] K_F: yeah for the records [21:09:52] so do we want to discuss #618254 more? its a closed bug, and we did discuss it already [21:10:30] we can, but in "closed session" afterwards [21:10:57] dilfridge: i don't really care to discuss it anymore [21:11:09] there's nothing urgent to do there atm [21:11:12] i mean we can add our opinions on the bug itself [21:11:45] okay is there anymore more to add about open bugs? [21:11:54] since agenda is light today anyways, lets do a 5-10 min on it in private channel just to be sure [21:12:02] after the open floor etc [21:12:18] don't necessarily believe there is much to discuss, but can share a bit of info on it [21:13:12] K_F: okay [21:14:41] also, I'd liek to request that council does a small vote [21:14:51] that editing package field should be left to maintainer [21:15:11] Soap__: issues for voting should be brought up as regular agenda items [21:15:13] Soap__: we're in the private channel, in a sec we'll get to the open floor and you can talk to use about your issue [21:15:34] K_F: seriously [21:15:35] K_F: trute but we can let him bring it up [21:15:41] then we have an open floor in the first place [21:15:42] sure, we can discuss it [21:15:44] Soap__: 1 sec okay [21:15:49] we/why [21:16:32] K_F ulm dilfridge continue discussion about bug #618254 in the private channel please [21:18:55] Soap__: immediately voting doesn't allow to research the subject matter to cast a well informed vote and therefore decision [21:19:23] leio: that topic has been discussed to death on the ML [21:20:48] I meant more in general, why it could be more of a rule or so. [21:21:43] and skimming stuff due to not being affected oneself and having to cast a vote are different things [21:22:52] correct, that is the basis for the rule/guideline [21:23:15] K_F: dilfridge ulm continuing in here [21:23:30] but we can discuss it, and if sufficient grounds can bring it up for a vote on bugtracker for between-meeting vote or next meeting [21:23:31] okay we're done with bugs, let's move to the open floor [21:24:14] Soap__: did you have something for open floor? [21:24:33] blueness: apparently no [21:24:46] because it needs to be on the agenda [21:25:03] Soap__: you can bring up the issue now, even if its not on the agenda [21:25:30] we may or may not discuss/vote depending on how serious it is [21:25:32] so yes [21:25:53] package field is maintainer territory [21:26:04] and only the maintainer should be able to edit it [21:26:20] just like only maintainers can call for stablization [21:26:45] this is like a no-brainer to pretty much everyone, but we apparently need everything black-on-white [21:27:10] I have asked before, but where is it stated that only maintainer can call for stabilization? [21:27:20] Soap__: the practice has been that people can request stabilization, but with the maintainers ack [21:27:41] this is what "call for stabilization" vs "ask" is [21:27:54] https://wiki.gentoo.org/wiki/Project:Bug-wranglers [21:28:04] "A stabilization request should be handled by the package's maintainer" [21:28:05] leio: okay i can accept that distinction [21:28:07] that is a bug wrangler policy document, so only for the project [21:28:16] ok [21:28:16] its not a global policy [21:28:21] two votes then [21:28:24] first vote [21:28:49] "only package maintainers are allowed to finalise stablization requests" [21:30:07] Soap__: we don't really have enough to vote on that, but please go on with your second motion and we'll continue the discussion [21:30:14] isn't there a way to get around such micro-management by the council? [21:30:23] ulm: apparently not [21:30:30] some people need every action to be codified [21:31:36] blueness: the idea is, first codify that package maintainers have the last say [21:32:00] then package field should not be touched by non-maintainer after arches were CCed [21:33:13] Soap__: what happened that brought this up as an issue, looking at that may address ulm 's concern [21:33:41] blueness: jer editing package fields en masse to suite his OCD for specific formats [21:33:50] ulm: well, that type of micromanagement becomes necessary when nobody dares to tell one person to behave or. [21:34:33] Soap__: did it change the packages to be stabilized? or was it just cosmetic? [21:34:37] I still don't like that we must go down to this level of micromanaging things [21:34:39] You never know. [21:34:53] blueness: thats the problem [21:34:55] without wasting time on checking. [21:34:59] it takes the maintainer a ton of effort to check [21:35:15] ulm: if people want action against persons for doing something, what they are doing should be against a policy [21:35:19] because bugzie diff on package field is next to useless for one char per line [21:35:45] K_F: yes, I see the problem [21:36:23] Soap__: i see [21:36:43] blueness: and unfortunately we need a policy for this [21:36:49] there are some immediate issues that comes up with a vote on the matter as it is stated, one of which is security project that routinely files stabilization requests [21:36:56] because explaining nicely why this makes no sense isnt enough [21:37:12] K_F: _after arches have been CCed_ [21:37:13] Soap__: that's sad [21:37:24] blueness: yip [21:37:32] this seems so unnecessary but i guess it is [21:37:33] Soap__: thats not part of the motion for first vote [21:37:48] no, it applies via the second [21:38:02] but the first would already invalidate the behavior [21:38:07] no [21:38:13] "only package maintainers are allowed to finalise stablization requests" [21:38:17] _finalise_ [21:38:19] not file [21:38:20] Soap__: okay i think this problem has merit but we need to discuss it on the list: 1) we don't have everyone and 2) the discussion on the list makes the issue clear to the entire community [21:38:43] Soap__: security routinely CCs arches without maintainer ack, as maintainers are somewhat slow.. [21:38:44] blueness: remember jer's e-mail on gentoo-core? [21:39:04] apparently [21:39:05] dilfridge: nope [21:39:12] a massive flamethread on gentoo-core isnt enough [21:39:18] subject "Puzzling bugzilla changes" [21:39:19] we need to bikeshed it over AGAIN [21:39:36] that was an attempt to drive the message home by different means [21:40:05] essentially I adapted all open bugs filed by jer to my own style ideas [21:41:17] i think we need to take a position on this [21:41:25] becasue apparently, in gentoo you now need to counter childish behaviour with more childish behaviour to raise awareness [21:41:34] (i need to feed the dog, about 2 mins) [21:42:05] ok, lets make it more specific then [21:42:23] giving the maintainer the final say seems reasonable (assuming maintainer is active) [21:42:35] "Once the bug has been finalised and arches have been CCed, no edits to the package field are permitted unless acknowledged by the bug reporter" [21:42:51] also, we could say what the format of the field is [21:43:00] ulm: even better! [21:43:04] Soap__: fwiw, likely want to avoid the term "finalised" in that context as it is not defined [21:43:08] /- [arches] [21:43:11] The original public thread on this, trying to avoid council micro-management, was https://archives.gentoo.org/gentoo-dev/message/6c938ff3f00601fce3916b2b297c04fa [21:44:21] (back) [21:44:46] K_F: change finalised to something of your liking + add the ulm definition [21:45:40] IIRC there was a better wording of that definition in the wiki somewhere [21:45:46] but I fail to find it [21:45:51] ulm: also maybe add "any other form that happens to work is not supported and not guaranteed to work" [21:46:31] i like ulm's idea of specifying the package list. [21:46:41] yeah, I have no issue with that [21:46:55] https://wiki.gentoo.org/wiki/Stable_request [21:46:59] i have to admit, i've been bad about filling in the package list myself and don't mind if someone fixes my oversite [21:46:59] "Package list - a fully qualified package per line, optionally followed by a space-delimited list of architectures to target." [21:47:29] ulm: fully qualified lets = open [21:48:12] not really, but let's make it /- to be very clear [21:48:20] -*- leio doesn't care about = or not, but cares about non-maintainers edits post-CC; and unexplained in comments edits pre-CC when not maintainer [21:49:00] leio: implicitly, that will fix the issue [21:49:02] but I agree [21:49:14] I think adding the edit-after should also be done [21:49:18] leio: the = is nice for arch testers because then htye can just copy and past, also our bots should have a fixed format to read from [21:49:24] you can not copy paste that list... [21:49:32] blueness: we discussed this like a million times [21:49:47] Soap__: what the format? [21:49:51] there is an optional arch listing after the $CATEGORY/$PF [21:50:06] blueness: package field is not portage format [21:50:19] and jer's forcing it is pointless and bug spam [21:50:29] note that if a line is empty, it implies all CC'ed architectures, and it can be empty for some lines and filled for others - thus you can't just grep 'arch' |cut -d' ' -f1 [21:51:13] Soap__: as long as we have some standard that maps 1:1 to what packages need to be stabilized, i'm okay [21:52:29] blueness: which we have [21:53:14] guys do we need to discuss this further here, we get the issue. i think we should have this discusson on gentoo-dev@ in preparation for the next council meeting to vote, even if we do repeat some issue [21:53:15] Soap__: then just say we want a council vote on this next time and refer to the seminal emails that frame the issue [21:53:21] we need to make sure that people understand this is going to be a council issue [21:53:42] blueness: its just bikeshedding again [21:53:50] we've had two massive threads on this [21:54:01] Soap__: i'm not going to vote on this today [21:54:02] I will propose the wording for the next time [21:54:34] Soap__: i didn't follow the issue but would have if i knew it was up for a vote [21:55:36] well then you must've lived under a rock [21:55:41] because this was a big deal [21:56:41] I don't really believe such characterisations are productive, but .. [21:56:48] Soap__: real life. that's why i'm stepping down from the council. nonetheless, we are not prepare to vote on this. [21:56:56] I second that the issue is not ready for a vote at this meeting [21:58:15] okay guys, then we are done unless there is another issue [21:58:26] Soap__: just bring it up for the next council to consider [21:58:34] I will [21:58:47] anything else? [22:00:19] K_F: dilfridge ulm i move to ajourn! [22:00:26] ack [22:00:38] dilfridge: at your leisure, please email me the log, thanks! [22:00:50] will do so in a moment, no problem [22:01:00] nothing from me, thanks to the current council for a good working relationship over the past year and good luck for elections for those chosing to accept nominations [22:01:44] yep. it was another interesting year, and it was over way faster than I thought... [22:01:59] dilfridge: very nice work on the decisions document [22:02:17] thanks... but it's not finished yet (and never will be I fear :P) [22:02:37] currently I'm somewhere 4/2010 with improving [22:03:15] :) [22:04:22] dilfridge: it'll be fine, as long as you're catching up with it faster than Tristam Shandy :) [22:04:31] hrhr [00:00:00] - {Tageswechsel: Montag, 12. Juni 2017}