path: root/meeting-logs/20170611.txt

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