path: root/meeting-logs/20190512.txt

[2019-05-12 - 21:00:08]<Whissi>		!proj council
[2019-05-12 - 21:00:08]<willikins>	Whissi: (council@gentoo.org) dilfridge, k_f, leio, slyfox, ulm, whissi, williamh
[2019-05-12 - 21:00:15]<Whissi>		mgorny / rich0: ping
[2019-05-12 - 21:00:26]<Whissi>		Let's get the 188th meeting started, agenda: https://archives.gentoo.org/gentoo-project/message/f13a423c093fef063d3d738154faa99c
[2019-05-12 - 21:00:37]<dilfridge>	yippi-ka-yay-yay
[2019-05-12 - 21:00:56]<veremitz>	lol
[2019-05-12 - 21:01:12]*		slyfox patiently awaits first roll call item
[2019-05-12 - 21:01:21]<Whissi>		Roll call. :)
[2019-05-12 - 21:01:25]*		ulm here
[2019-05-12 - 21:01:25]*		slyfox here
[2019-05-12 - 21:01:26]*		leio here
[2019-05-12 - 21:01:28]*		WilliamH here
[2019-05-12 - 21:01:30]*		Whissi here
[2019-05-12 - 21:01:31]*		dilfridge here();
[2019-05-12 - 21:01:34]*		K_F here
[2019-05-12 - 21:01:40]<Whissi>		\o/
[2019-05-12 - 21:01:58]<Whissi>		2. GLEP 63 change request
[2019-05-12 - 21:02:13]<Whissi>		A motion was proposed by Rich Freeman (rich0) to change GLEP 63 to remove
[2019-05-12 - 21:02:13]<Whissi>		key requirement that signing subkey must be different from the primary key
[2019-05-12 - 21:02:13]<Whissi>		and does not have any other capabilities enabled.
[2019-05-12 - 21:02:13]<Whissi>		https://archives.gentoo.org/gentoo-dev/message/d05070a200e4f5858642d308d9b3e39f
[2019-05-12 - 21:02:30]*		WilliamH is ok with it
[2019-05-12 - 21:02:31]<mgorny>		Whissi: thanks
[2019-05-12 - 21:02:53]<K_F>		changing it is a bad idea
[2019-05-12 - 21:02:54]<slyfox>		no word from security@?
[2019-05-12 - 21:03:13]<K_F>		I get rich0's point, but its not a good one
[2019-05-12 - 21:03:46]<Whissi>		I don't see a need to force you to do it right. If you want to do it wrong... well, this is Gentoo. That's my POV. I allow everyone to shoot him/herself. :)
[2019-05-12 - 21:03:56]<WilliamH>	Whissi++
[2019-05-12 - 21:04:07]<K_F>		that only works if only you get hurt
[2019-05-12 - 21:04:19]<K_F>		setting minimal security standards is about protecting the overall ecosystem
[2019-05-12 - 21:04:27]*		veremitz cough*rubber-bullets*cough :\ /stfu
[2019-05-12 - 21:04:27]<K_F>		and having separate signing key is good practice in general
[2019-05-12 - 21:04:29]<dilfridge>	well, different approaches address different threat models
[2019-05-12 - 21:04:55]<rich0>		IMO there is no threat model that would compromise end-user systems that is prevented by the current policy that would not also be prevented by the proposed change.
[2019-05-12 - 21:05:05]<Whissi>		K_F: How can this affect you? I mean, if I don't trust your subkey, I will never send you encrypted mails. No matter what GLEP says "That's fine" 
[2019-05-12 - 21:05:10]<mgorny>		the problem is, rich is claiming his solution to be as secure as the current one while it's false claim
[2019-05-12 - 21:05:29]<K_F>		Whissi: Dev X commits bad code in repo?
[2019-05-12 - 21:05:42]<Whissi>		mgorny: I agree with that. The claim from rich0 is wrong.
[2019-05-12 - 21:05:43]<K_F>		woops, key was stolen ..
[2019-05-12 - 21:06:03]<K_F>		and that means full primary compromise
[2019-05-12 - 21:06:05]<Whissi>		K_F: But the current enforcement doesn't avoid the problem, does it?
[2019-05-12 - 21:06:17]<zlogene>	slyfox: has been discussed within security@ a bit, onkey generation does not allow you to backup the primary key, which is not nice
[2019-05-12 - 21:06:21]<K_F>		it makes it easier to correct it once it happens, in any case
[2019-05-12 - 21:06:35]<K_F>		whether it helps it sort of depens on forcesig true or false
[2019-05-12 - 21:06:42]<rich0>		The current policy allows online unprotected primary keys.  Having them stored in a smartcard but being used as signing keys as well is no less secure than that.
[2019-05-12 - 21:06:44]<Whissi>		I mean, how do you want to control that I don't have a key copy in dev.gentoo.org/~whissi/.gpg? :-)
[2019-05-12 - 21:07:00]<K_F>		right, that part of the problem you can't solve technically
[2019-05-12 - 21:07:07]<K_F>		its a social problem
[2019-05-12 - 21:07:08]<Whissi>		Unless we can control, I don't see a need to enforce something else.
[2019-05-12 - 21:07:28]<dilfridge>	only oncard generation + primary on card ----> it's not possible to steal the key, but it is possible to generate fake subkeys / sigs
[2019-05-12 - 21:07:41]<K_F>		we can control how the structure of the key material is..
[2019-05-12 - 21:07:58]<rich0>		dilfridge: only with access to the card, but sure, but that also applies to online primary keys.
[2019-05-12 - 21:08:00]<Whissi>		dilfridge: And how do you know if key was generated on card? This would require pre-enrolled keys...
[2019-05-12 - 21:08:05]<dilfridge>	right
[2019-05-12 - 21:08:07]<K_F>		dilfridge: its more complex than that, it only works in scenario where infra generates the key and ships it to dev
[2019-05-12 - 21:08:19]<rich0>		Whissi: you don't, just as you don't know if somebody is keeping their primary key offline.
[2019-05-12 - 21:08:31]<zlogene>	dilfridge: and breakage -> goodbye WOT
[2019-05-12 - 21:08:37]<K_F>		as you'd do in corporate environments, where employees don't really require access to primary keys
[2019-05-12 - 21:09:00]<Whissi>		Yup. But in corportate environments, you don't own your key.
[2019-05-12 - 21:09:06]<K_F>		but yes, loss of primary is by design considered much more serious than loss of a subkey
[2019-05-12 - 21:09:07]<Whissi>		*corporate
[2019-05-12 - 21:09:17]<ulm>		could we move the "signing subkey is different" part from requirements to recommendations?
[2019-05-12 - 21:09:30]<K_F>		Whissi: nothing different between that and Gentoo per se
[2019-05-12 - 21:09:46]<K_F>		ulm: we can do anything the council wants, my vote is no
[2019-05-12 - 21:09:49]<mgorny>		ulm: 'recommendations' are pointless
[2019-05-12 - 21:09:52]<WilliamH>	rich0: What do you think about what uljm said above?
[2019-05-12 - 21:09:56]<WilliamH>	ulm *
[2019-05-12 - 21:10:04]<mgorny>		you either make requirements, and enforce them
[2019-05-12 - 21:10:07]<ulm>		mgorny: then why are they even there?
[2019-05-12 - 21:10:10]<dilfridge>	I want a pony.
[2019-05-12 - 21:10:11]<rich0>		WilliamH: I'd be happy to update the draft to do that if people want to make it a recommendation
[2019-05-12 - 21:10:31]<mgorny>		ulm: 'recommendations' are for things we can't technically enforce
[2019-05-12 - 21:10:48]<mgorny>		otherwise they're just noise
[2019-05-12 - 21:11:06]<rich0>		many of the current recommendations can be technically enforced
[2019-05-12 - 21:11:32]<rich0>		IMO that shouldn't matter.  You can have separate requirements and recommendations, recognizing that sometimes situations vary.
[2019-05-12 - 21:12:01]<WilliamH>	rich0++
[2019-05-12 - 21:12:22]<mgorny>		making separate subkey a recommendation basically means we'd issue permanent warnings to a number of devs
[2019-05-12 - 21:12:30]<mgorny>		then they will complain that we're bothering them
[2019-05-12 - 21:12:38]<WilliamH>	a recomendation is a statement of what we prefer, but we don't stop you if you don't.
[2019-05-12 - 21:12:40]<mgorny>		because they chose not to follow recommendations
[2019-05-12 - 21:12:47]<rich0>		Do we issue warnings to anybody using ECC keys?
[2019-05-12 - 21:13:17]<rich0>		Or with an expiry > 365d out?
[2019-05-12 - 21:13:31]<WilliamH>	mgorny: you don't necessarily issue a warning for someone not following a recommendation.
[2019-05-12 - 21:13:33]<rich0>		We're not obligated to harass people with warnings.  They may or may not be useful.
[2019-05-12 - 21:13:42]<WilliamH>	rich0++
[2019-05-12 - 21:14:00]<mgorny>		rich0: expiration has been changed from recommendation to requireement for this precise reason
[2019-05-12 - 21:14:18]<Whissi>		My problem with this requirement is that we somehow say "this is the only secure way". But like said, if I keep a copy of my key somewhere else, this could be a problem. => Current enforcement is some kind of security through obscurity because we don't control 100% and just assume that this requirement is more secure but we cannot say that for sure.
[2019-05-12 - 21:14:26]<mgorny>		rich0: so, please tell me, how do we encourage using separate signing subkey?
[2019-05-12 - 21:14:40]<mgorny>		i get that you don't believe in it, and you think your 'offline' solution that's not offline is better
[2019-05-12 - 21:14:51]<mgorny>		but if it stays as recommendation, it should be recommended to developers
[2019-05-12 - 21:15:11]<mgorny>		unless ofc the purpose is merely to shove it under the carpet
[2019-05-12 - 21:15:24]<mgorny>		and use neat wording to silence people opposed to it
[2019-05-12 - 21:15:35]<rich0>		mgorny: well, for starters if you want to encourage people to keep their primary keys offline, you might want to put that in the recommendations at least
[2019-05-12 - 21:16:15]<ulm>		hm, but it's currently only a recommendation the the primary key has no signing capability
[2019-05-12 - 21:16:19]<ulm>		so you could have primary key with CS and additional signing key with S
[2019-05-12 - 21:16:21]<rich0>		It seems like you're just assuming that anybody with a separate signing key would keep their primary key offline, with no docs at all even suggesting that people do this.  It probably isn't obvious to most people using gpg that they would even want to do this.
[2019-05-12 - 21:16:22]<mgorny>		yeah, i guess not saying that explicitly is a major miss
[2019-05-12 - 21:16:26]<K_F>		ulm: sure
[2019-05-12 - 21:16:33]<dilfridge>	I would say having the whole key on the smartcard is safer than having the whole key on your harddisk
[2019-05-12 - 21:16:39]<ulm>		and primary stored on smartcard
[2019-05-12 - 21:16:41]<mgorny>		ulm: it's recommendation because removing S cap from existing key invalidates signatures
[2019-05-12 - 21:16:57]<mgorny>		it does not need to be enforced when there is a separate signing subkey since gpg will use that instead
[2019-05-12 - 21:17:20]<K_F>		well, in the on-disk scenario it does, as if subkey expires it will use the primary anyways
[2019-05-12 - 21:17:29]<K_F>		but the assumption is gentoo developers actually care about security
[2019-05-12 - 21:17:38]<mgorny>		K_F: but then the hook rejects the key
[2019-05-12 - 21:17:40]<K_F>		if they don't I sort of question whether they should have commit access to begin with
[2019-05-12 - 21:17:47]<ulm>		mgorny: won't it use the primary key if the subkey is unavailable?
[2019-05-12 - 21:18:07]<mgorny>		ulm: i dunno, K_F? ^
[2019-05-12 - 21:18:11]<K_F>		gpg will
[2019-05-12 - 21:18:43]<K_F>		but of course the primary is offline so you don't actually end up signing without going to airgapped system
[2019-05-12 - 21:18:52]*		dilfridge rolls eyes
[2019-05-12 - 21:19:07]<mgorny>		dilfridge: sure but is this more gain than from having separate primary key? i doubt it
[2019-05-12 - 21:19:12]<WilliamH>	imo if we are going to make all of these deep gpg requirements, we should have a document that explains in detail how to do this since most people don't really know how to use gpg at this level.
[2019-05-12 - 21:19:21]<rich0>		IMO it is more productive to actually document best practices and encourage devs to follow them, rather than setting traps and then complaining about people who don't manage to figure out what level of security/paranoia is appropriate.  We obviously can't make every rule explicit, or prevent people from gaming the system, but if we want people to do something, we ought to at least be up-front about it.
[2019-05-12 - 21:19:25]<dilfridge>	K_F: the problem is, when you make unrealistic assumptions about what people do for security, you end up with unrealistic recommendations
[2019-05-12 - 21:19:45]<rich0>		WilliamH: ++
[2019-05-12 - 21:19:47]<K_F>		its our job to set the standard and rise the bar
[2019-05-12 - 21:19:51]*		NeddySeagoon 's eyes glaze over
[2019-05-12 - 21:19:55]<mgorny>		the problem is, if you use single C+S key, hardware and software don't differentiate between them
[2019-05-12 - 21:20:12]<mgorny>		so if you unluck the key for signing (which you need to do if you are doing any serious gentoo work)
[2019-05-12 - 21:20:21]<mgorny>		the C capability is open to sign anything as well
[2019-05-12 - 21:20:31]<rich0>		mgorny: just require a PIN on each sign event
[2019-05-12 - 21:20:39]<rich0>		which is the default anyway on our nitrokeys
[2019-05-12 - 21:20:40]<K_F>		its quite easy to trick that
[2019-05-12 - 21:20:42]<Whissi>		For me the only question is: Do we want to allow Gentoo devs to shoot themselves or not. If we don't want to allow that -> No GLEP change. If we want to allow that -> Some requirements must be converted into requirements.
[2019-05-12 - 21:20:56]<Whissi>		*recommendations
[2019-05-12 - 21:20:56]<mgorny>		rich0: which is completely impossible to use if you are going to ever make more than 2 commits at a time
[2019-05-12 - 21:21:06]<mgorny>		you should probably know that if you are following glep 66
[2019-05-12 - 21:21:13]<K_F>		a malware on your computer will present it as a regular signing, but it does a subkey generation instead and voilla free commit access
[2019-05-12 - 21:21:15]<WilliamH>	Doesn't all of this mean you have to insert your hardware key  every time you want to sign a commit etc?
[2019-05-12 - 21:21:26]<rich0>		WilliamH: sure
[2019-05-12 - 21:21:33]<rich0>		That's kind of the point
[2019-05-12 - 21:21:49]<rich0>		And if it isn't inserted, then nobody can access your key
[2019-05-12 - 21:22:10]<dilfridge>	so how long is it inserted after you've done a signature?
[2019-05-12 - 21:22:32]<rich0>		dilfridge: I imagine that depends on the individual, and your risk also depends on whether you require a PIN on every sign.
[2019-05-12 - 21:22:32]<Whissi>		You can control how long GPG agent should cache...
[2019-05-12 - 21:23:07]<ulm>		https://xkcd.com/538/
[2019-05-12 - 21:23:12]<rich0>		There are a LOT of ways you can do things under either the existing GLEP or with my proposed change.  They all have pros/cons in terms of convenience and security.
[2019-05-12 - 21:23:18]<veremitz>	@22min in .. defer?!
[2019-05-12 - 21:23:19]<K_F>		forcesig would make a difference, but if asked often enough it isn't necessarily useful and its easy enough to misdirect
[2019-05-12 - 21:23:37]<K_F>		in any case just vote, I'll have my "no" recorded and it passes and we've made a decision..
[2019-05-12 - 21:23:51]<K_F>		I don't think anyone's minds will change much anyways
[2019-05-12 - 21:23:53]<gokturk>	dilfridge: yubikey requires pin on every sign with an optional feature to require physical touch to the device
[2019-05-12 - 21:24:19]<K_F>		gokturk: yeah, the touch part is quite nice on youbikey
[2019-05-12 - 21:24:28]<K_F>		forcesig is OpenPGP applet part of the spec
[2019-05-12 - 21:24:31]<K_F>		which is toggable
[2019-05-12 - 21:24:42]<K_F>		see forcesig
[2019-05-12 - 21:24:46]<rich0>		IMO part of the issue is that the GLEP is oriented around things like key lengths and configurations, and we're making assumptions about storage/workflow/etc.
[2019-05-12 - 21:25:10]<rich0>		The GLEP is focused on stuff we can enforce, and not necessary what adds the most actual security.
[2019-05-12 - 21:25:10]<Whissi>		OK, just a vote about current proposed change or do we want to include option to defer for a new proposal converting some requirements into recommendations?
[2019-05-12 - 21:25:31]<K_F>		Whissi: that is a new case anyways
[2019-05-12 - 21:25:33]<rich0>		Whissi: up to you guys, but I'd suggest doing it as-is first, and if it fails try again with the recommendation approach
[2019-05-12 - 21:25:42]<K_F>		so I say vote for current proposed change
[2019-05-12 - 21:26:32]<Whissi>		OK. Please vote: Accept GLEP 63 change request like shown in https://archives.gentoo.org/gentoo-dev/message/d05070a200e4f5858642d308d9b3e39f? Yes/No.
[2019-05-12 - 21:26:38]*		K_F no
[2019-05-12 - 21:26:41]*		leio no
[2019-05-12 - 21:26:46]*		WilliamH yes
[2019-05-12 - 21:26:51]*		dilfridge no
[2019-05-12 - 21:26:53]*		Whissi no
[2019-05-12 - 21:26:55]*		slyfox abstains
[2019-05-12 - 21:27:21]*		ulm abstains
[2019-05-12 - 21:27:34]<rich0>		Whissi: if you're willing could I at least get a sense of whether the recommendation approach is likely to pass, and then come back with actual wording later?
[2019-05-12 - 21:27:44]<Whissi>		Motion was rejected.
[2019-05-12 - 21:27:47]<rich0>		Rather than wasting 25min on the next agenda if nobody is actually interested in that...
[2019-05-12 - 21:28:15]<K_F>		rich0: I recommend taking it on ML and not spending more time on it in this meeting
[2019-05-12 - 21:28:17]<Whissi>		Not sure if we can vote if someone would accept a proposal he/she hasn't seen before...
[2019-05-12 - 21:28:39]<WilliamH>	So who is going to write the detailed docs on how to create our keys?
[2019-05-12 - 21:28:40]<slyfox>		As a user I would be happy to have a document that describes how to set up and use gpg key with recommentations.
[2019-05-12 - 21:28:45]<rich0>		I'm happy to post it on the list, but it seems silly to iterate monthly when most haven't even replied to the existing policy on-list.
[2019-05-12 - 21:28:54]<WilliamH>	slyfox++
[2019-05-12 - 21:29:02]<K_F>		slyfox: we have it in wiki, in addition to man gpg and info gnupg
[2019-05-12 - 21:29:19]<K_F>		but that is also a ML topic
[2019-05-12 - 21:29:23]<ulm>		rich0: my impression is that even moving to recommendations won't be accepted
[2019-05-12 - 21:29:33]<slyfox>		K_F: it's not an answer
[2019-05-12 - 21:29:35]<rich0>		ulm: that was your proposal.  Would you vote for it?
[2019-05-12 - 21:29:40]<WilliamH>	slyfox++
[2019-05-12 - 21:29:48]<K_F>		slyfox: it really is...
[2019-05-12 - 21:29:51]<rich0>		I don't want to just waste everybody's time, including my own.
[2019-05-12 - 21:29:52]<Whissi>		slyfox / WilliamH: https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys
[2019-05-12 - 21:29:55]<ulm>		rich0: depends on the exact wording
[2019-05-12 - 21:30:01]<rich0>		We can just stick with online primary keys I suppose.
[2019-05-12 - 21:30:13]<K_F>		security is as much about operational security as technical, if you don't understand the implications and context it doesn't matter if you follow the actual edit commands
[2019-05-12 - 21:30:34]<mgorny>		rich0: even online primary key is better than combined C+S key
[2019-05-12 - 21:30:40]<mgorny>		as you can protect the primary key better
[2019-05-12 - 21:30:46]<mgorny>		not that gpg makes this easy but it's possible
[2019-05-12 - 21:31:00]<K_F>		well, separate passphrase actually helps a tad in theory
[2019-05-12 - 21:31:07]<mgorny>		but please move to the next topic, it's 30 mins to midnight
[2019-05-12 - 21:31:14]<Whissi>		OK, let's move on. rich0, feel free to propose something new on mailing list if you like...
[2019-05-12 - 21:31:42]<Whissi>		3. GLEP 48 approval requested: Michal G�rny (mgorny) requested council to approve current GLEP 48 draft (v3 as of today) which would clarify QA project's privileges to issue disciplinary actions. https://archives.gentoo.org/gentoo-project/message/a9d6dc3cf28345a2e96c2cfd164226f2
[2019-05-12 - 21:32:14]<dilfridge>	ok can we please just immediately vote on this?
[2019-05-12 - 21:32:14]<zlogene>	I call it "remove comrel from there for short bans"
[2019-05-12 - 21:32:33]<zlogene>	so please _REMOVE_ comrel for short bans
[2019-05-12 - 21:32:37]<ulm>		30 days are way too long, though
[2019-05-12 - 21:32:39]<WilliamH>	I'm fine with an immediate vote.
[2019-05-12 - 21:32:43]<zlogene>	and I will buy dilfridge a beer
[2019-05-12 - 21:32:58]<dilfridge>	hic
[2019-05-12 - 21:32:59]<Whissi>		I have also sent my thoughts to ml and agree with ulm.
[2019-05-12 - 21:33:15]<Whissi>		leio / K_F: Do you want to add something or can I call for vote?
[2019-05-12 - 21:33:23]<ulm>		I'd be fine with 14 days at most
[2019-05-12 - 21:33:35]<WilliamH>	Can't the proctors ban someone from mls etc for up to 30 days?
[2019-05-12 - 21:33:38]<leio>		I'm good
[2019-05-12 - 21:33:40]<K_F>		Whissi: I'm good
[2019-05-12 - 21:33:46]<zlogene>	ulm: not realistic
[2019-05-12 - 21:33:47]<mgorny>		ulm: as i said, convince the proctors to the same change
[2019-05-12 - 21:33:49]<ulm>		WilliamH: good point
[2019-05-12 - 21:33:56]<zlogene>	if the deal passed to comrel
[2019-05-12 - 21:34:01]<Whissi>		OK. Please vote: Accept GLEP 48 change request like shown in https://archives.gentoo.org/gentoo-project/message/a9d6dc3cf28345a2e96c2cfd164226f2? Yes/No.
[2019-05-12 - 21:34:01]<mgorny>		i don't see why rules should be different
[2019-05-12 - 21:34:11]*		ulm no
[2019-05-12 - 21:34:12]*		Whissi no
[2019-05-12 - 21:34:14]*		WilliamH yes
[2019-05-12 - 21:34:14]*		dilfridge yes
[2019-05-12 - 21:34:17]*		slyfox no
[2019-05-12 - 21:34:21]*		leio abstain
[2019-05-12 - 21:34:26]*		K_F yes
[2019-05-12 - 21:34:31]<dilfridge>	not passed
[2019-05-12 - 21:34:48]<Whissi>		Motion hasn't passed.
[2019-05-12 - 21:34:49]<veremitz>	chair has casting vote?! :P
[2019-05-12 - 21:35:08]<ulm>		veremitz: tie vote
[2019-05-12 - 21:35:10]<veremitz>	[still no :P]
[2019-05-12 - 21:35:19]<dilfridge>	ok suggest, we re-run the vote with 30days -> 15 days
[2019-05-12 - 21:35:19]<veremitz>	ulm: tie not aresult ;)
[2019-05-12 - 21:35:21]<WilliamH>	Before this was put on paper, the qa lead could go directly to infra and ban someone.
[2019-05-12 - 21:35:27]<Whissi>		So I guess we will get v4...
[2019-05-12 - 21:36:02]<WilliamH>	If we do that, I think we have to make the proctors make the same change.
[2019-05-12 - 21:36:11]<dilfridge>	not really
[2019-05-12 - 21:36:14]<dilfridge>	who cares
[2019-05-12 - 21:36:27]*		WilliamH thinks  it should be consistent
[2019-05-12 - 21:36:27]<dilfridge>	but this topic needs to get off the table, because we're
[2019-05-12 - 21:36:32]<K_F>		WilliamH: its different cases anyways, so doesn't necessarily matter much, and CoC can require longer to calm down
[2019-05-12 - 21:36:33]<zlogene>	dilfridge: -> beer -> next time
[2019-05-12 - 21:36:37]<K_F>		i.e CoC situations
[2019-05-12 - 21:36:43]<K_F>		so I don't agree on a 1:1 link
[2019-05-12 - 21:36:49]<dilfridge>	actually *only* writing down what was the informal policy for the last years anyway
[2019-05-12 - 21:36:55]<Whissi>		I am also not happy about "negatively impact the behavior of Gentoo systems, work of other developers  or infrastructure facilities" so I would like to see v4.
[2019-05-12 - 21:37:20]<mgorny>		well, my alternative proposal is to abolish glep 48 altogether
[2019-05-12 - 21:37:22]<rich0>		WilliamH: fwiw, in the case of proctors the long bans are appealable to comrel
[2019-05-12 - 21:37:39]<mgorny>		i don't see why qa needs to waste so much time in trying to write a policy that people are going to bikeshed to death
[2019-05-12 - 21:37:40]<WilliamH>	dilfridge: informal policy was, deigo could go straight to infra and ban someone. ;-)
[2019-05-12 - 21:37:46]<WilliamH>	diego *
[2019-05-12 - 21:37:49]<leio>		same in this glep change proposal
[2019-05-12 - 21:37:50]<mgorny>		while comrel is governing itself as they see fit
[2019-05-12 - 21:37:52]<leio>		(appeal)
[2019-05-12 - 21:37:55]<leio>		(to council)
[2019-05-12 - 21:37:56]<dilfridge>	Whissi:  please re-run the vote with 30days -> 15 days and no other change
[2019-05-12 - 21:38:08]<Whissi>		(QA is for gentoo.git and not to protect developers or infrastructure. Maybe I read it wrong but these words must change)
[2019-05-12 - 21:38:19]<veremitz>	mgorny: +1
[2019-05-12 - 21:38:49]<zlogene>	Whissi: you read it wrong
[2019-05-12 - 21:38:50]<dilfridge>	WilliamH: independent of what we decide here and now, no infra lead will refuse blocking someones commit access for formal reasons if there is clear and present danger of damage
[2019-05-12 - 21:38:59]<zlogene>	qa brakages can affect the infra
[2019-05-12 - 21:39:20]<veremitz>	dilfridge: define "formal reasons" - thats the problem.
[2019-05-12 - 21:39:24]<Whissi>		Infra don't need QA for protection.
[2019-05-12 - 21:39:48]<dilfridge>	gentlemen, I apologize in advance for this, but
[2019-05-12 - 21:39:55]*		dilfridge sets ban on veremitz!*@*
[2019-05-12 - 21:39:59]<zlogene>	we do not protect infra
[2019-05-12 - 21:40:00]*		dilfridge has kicked veremitz from #gentoo-council (Go back to preschool.)
[2019-05-12 - 21:40:08]<Whissi>		OK. Please vote: Accept GLEP 48 change request like shown in https://archives.gentoo.org/gentoo-project/message/a9d6dc3cf28345a2e96c2cfd164226f2 but with 15d instead of 30d max ban time? Yes/No.
[2019-05-12 - 21:40:21]*		slyfox no
[2019-05-12 - 21:40:23]*		Whissi no
[2019-05-12 - 21:40:25]*		dilfridge yes
[2019-05-12 - 21:40:28]<ulm>		dilfridge: we agreed in a previous meeting that only the chair should ban
[2019-05-12 - 21:40:44]*		mgorny knew instead of sleep he'll hear another discussion about chair banning people
[2019-05-12 - 21:40:46]<WilliamH>	dilfridge++
[2019-05-12 - 21:40:50]*		K_F yes
[2019-05-12 - 21:40:56]*		leio abstain
[2019-05-12 - 21:41:00]<gokturk>	dilfridge++ indeed
[2019-05-12 - 21:41:00]<dilfridge>	it's always easier to ask for forgiveness later
[2019-05-12 - 21:41:02]*		ulm no (I said before I would be o.k. with 14 days at most)
[2019-05-12 - 21:41:42]<Whissi>		WilliamH? Please vote.
[2019-05-12 - 21:42:10]<dilfridge>	doesnt matter anymore, motion not passed
[2019-05-12 - 21:42:20]*		WilliamH abstains
[2019-05-12 - 21:42:29]<mgorny>		Whissi: are you going to call another vote with 14d, so i could be angry with ulm for wasting time over one day?
[2019-05-12 - 21:43:39]<Whissi>		Given that ulm is also QA deputy... I am not sure if we should vote until we pass a motion. That's not BREXIT.
[2019-05-12 - 21:43:53]<WilliamH>	It doesn't matter that he is qa deputy
[2019-05-12 - 21:43:58]<Whissi>		But maybe we can vote in bug about v4 if QA project find a proposal they agree on
[2019-05-12 - 21:43:59]<zlogene>	Whissi: deputy is irrelevant
[2019-05-12 - 21:44:10]*		dilfridge hoped we'd be more efficient than the House of Commons...
[2019-05-12 - 21:44:41]<WilliamH>	This is exactly why I proposed banning qa and comrel members from council
[2019-05-12 - 21:44:43]<mgorny>		Whissi: 'QA deputy' means he's supposed to step up when lead is not available, not boss around like he was the lead
[2019-05-12 - 21:45:21]<Whissi>		WilliamH: I agree on that...
[2019-05-12 - 21:45:29]<Whissi>		Well, I don't care. Should I start a new vote for 14d?
[2019-05-12 - 21:45:36]<slyfox>		sure
[2019-05-12 - 21:45:41]<WilliamH>	Whissi: your call
[2019-05-12 - 21:45:43]<ulm>		mgorny: what is unclear about "his actions and decisions should be considered equal to those of the QA team lead"?
[2019-05-12 - 21:45:46]<dilfridge>	make it 13 to account for rounding errors
[2019-05-12 - 21:45:55]<ulm>		Whissi: yes please
[2019-05-12 - 21:46:10]<Whissi>		OK. Please vote: Accept GLEP 48 change request like shown in https://archives.gentoo.org/gentoo-project/message/a9d6dc3cf28345a2e96c2cfd164226f2 but with 14d instead of 30d max ban time? Yes/No.
[2019-05-12 - 21:46:16]*		K_F yes
[2019-05-12 - 21:46:17]*		Whissi no
[2019-05-12 - 21:46:21]*		dilfridge yes
[2019-05-12 - 21:46:22]*		leio abstain
[2019-05-12 - 21:46:31]*		slyfox no
[2019-05-12 - 21:46:46]*		ulm ye
[2019-05-12 - 21:46:50]<ulm>		*yes
[2019-05-12 - 21:47:15]*		WilliamH abstain -- in protest of the behavior of the rest of the council
[2019-05-12 - 21:47:36]<Whissi>		Motion passed.
[2019-05-12 - 21:48:19]<Whissi>		mgorny: Please update draft, post in bug and after ACK you can commit.
[2019-05-12 - 21:48:33]<mgorny>		tomorrow
[2019-05-12 - 21:48:35]<WilliamH>	ulm: wrt qa deputy, to me it means that you are the lead's backup. the lead can override you.
[2019-05-12 - 21:48:57]<K_F>		separate discussion out of scope now anyways
[2019-05-12 - 21:49:06]<ulm>		WilliamH: yes (and all of that is in the GLEP)
[2019-05-12 - 21:49:07]<mgorny>		and he shouldn't go out of his way to contradict the lead
[2019-05-12 - 21:49:16]<WilliamH>	mgorny++
[2019-05-12 - 21:49:29]<Whissi>		4. Registration request for EFI system partition subdirectory namespace: This one is just an information.
[2019-05-12 - 21:49:32]<leio>		I guess if someone feels strongly about some of the wording still, there can be yet another update proposal for a future meeting
[2019-05-12 - 21:49:34]<zlogene>	mgorny++
[2019-05-12 - 21:49:48]<K_F>		Whissi: nothing for us to do on it, the request has been sent
[2019-05-12 - 21:50:00]<K_F>		it doesn't require council involvement anyways
[2019-05-12 - 21:50:12]<Whissi>		antarus started registration but they haven't added us yet.
[2019-05-12 - 21:50:16]<WilliamH>	K_F++ on this one.
[2019-05-12 - 21:50:20]*		ulm still wonders about "gentoo" vs "Gentoo"
[2019-05-12 - 21:50:27]<WilliamH>	There's no need for council action.
[2019-05-12 - 21:50:46]<Whissi>		5. 17.1 profile stabilization
[2019-05-12 - 21:50:56]<WilliamH>	let's do it.
[2019-05-12 - 21:51:02]<Whissi>		Michal G�rny (mgorny) requested council to mark 17.1 profile stable: https://archives.gentoo.org/gentoo-project/message/d0358901301850b6e41f0ae9d26cef36
[2019-05-12 - 21:51:22]<Whissi>		Anyone wants to share something or can I start a vote?
[2019-05-12 - 21:51:29]<ulm>		this is long overdue IMHO
[2019-05-12 - 21:51:30]<dilfridge>	vote
[2019-05-12 - 21:51:33]<K_F>		vote
[2019-05-12 - 21:52:02]<dilfridge>	oh, wait, I still have this interesting story from my youth...
[2019-05-12 - 21:52:07]<ulm>		mgorny: will there be another news item?
[2019-05-12 - 21:52:27]<mgorny>		do we need one?
[2019-05-12 - 21:52:37]<ulm>		I'm asking you :)
[2019-05-12 - 21:52:52]<WilliamH>	mgorny: imo it is debatable that we need one.
[2019-05-12 - 21:52:59]*		rich0 has quit (Quit: rich0)
[2019-05-12 - 21:53:17]<dilfridge>	well, the more interesting question is, how do we get as many people as possible to migrate?
[2019-05-12 - 21:53:34]<slyfox>		you deprecate previous profile
[2019-05-12 - 21:53:36]<WilliamH>	drop deprecated files in the 17.0 amd64 profiles...
[2019-05-12 - 21:53:36]<dilfridge>	given that at some point we will want to deprecate and remove the 17.0 profiles
[2019-05-12 - 21:54:01]<WilliamH>	imo we can deprecate them and allow a migration period before removal.
[2019-05-12 - 21:54:07]<dilfridge>	yes, unfortunately the message from the deprecated file is rather short
[2019-05-12 - 21:54:12]<mgorny>		imo we don't need a new news item but we should update the old one to say they're not experimental anymore
[2019-05-12 - 21:54:17]<dilfridge>	and in this context not helpful
[2019-05-12 - 21:54:25]<dilfridge>	mgorny++
[2019-05-12 - 21:54:32]<K_F>		that wfm
[2019-05-12 - 21:54:36]<WilliamH>	mgorny: will it redisplay for people still using old profiles?
[2019-05-12 - 21:54:55]<mgorny>		WilliamH: just wanted to say that in this case we should probably bump the date too and have them redisplayed
[2019-05-12 - 21:54:58]<dilfridge>	yes
[2019-05-12 - 21:55:10]<mgorny>		i recall someone posted an update already but i think it wasn't committed in the end
[2019-05-12 - 21:55:15]<WilliamH>	mgorny: Agreed, it should redisplay.
[2019-05-12 - 21:55:17]<mgorny>		or at least i don't see it
[2019-05-12 - 21:55:18]<dilfridge>	good idea, and also write that the old profiles will be deprecated sometime soon
[2019-05-12 - 21:55:42]<Whissi>		Let's define a date. 6 or 12 month
[2019-05-12 - 21:55:44]<mgorny>		Whissi: i'd propose voting for change to stable after news item update is sent for review
[2019-05-12 - 21:55:50]*		rich0 (~quassel@gentoo/developer/rich0) has joined
[2019-05-12 - 21:55:50]*		ChanServ gives voice to rich0
[2019-05-12 - 21:56:06]<WilliamH>	Whissi: a date for what, deprecation or removal? they are two dates.
[2019-05-12 - 21:56:13]<K_F>		lets do deprecation as separate item on later meeting, it also depends on whether we see breakages when things are rolled out
[2019-05-12 - 21:56:33]<WilliamH>	Whissi: imo we can deprecate now along with the newsitem and remove in 6 or 12 months -- I would vote for 6.
[2019-05-12 - 21:56:37]<K_F>		no need to force it on given date
[2019-05-12 - 21:56:50]<K_F>		and the news item is for marking 17.1 stable
[2019-05-12 - 21:56:50]<dilfridge>	news item now, deprecation in 1 month if no further breakages occur, removal another 6 months later
[2019-05-12 - 21:56:56]<K_F>		ehrm, the agenda item
[2019-05-12 - 21:57:01]<WilliamH>	dilfridge: sounds reasonable.
[2019-05-12 - 21:57:17]<Whissi>		OK. Please vote: Mark 17.1 profiles stable like requested in https://archives.gentoo.org/gentoo-project/message/d0358901301850b6e41f0ae9d26cef36 but with additional (or old, updated) news item? Yes/No.
[2019-05-12 - 21:57:24]*		K_F yes
[2019-05-12 - 21:57:24]*		slyfox yes
[2019-05-12 - 21:57:28]*		dilfridge yes
[2019-05-12 - 21:57:28]*		WilliamH yes
[2019-05-12 - 21:57:29]*		Whissi yes
[2019-05-12 - 21:57:35]*		leio yes
[2019-05-12 - 21:57:43]*		ulm yes
[2019-05-12 - 21:57:49]<Whissi>		\o/ -- Passed.
[2019-05-12 - 21:58:25]<Whissi>		6. Open bugs with council involvement: https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
[2019-05-12 - 21:58:55]<Whissi>		bug 542498
[2019-05-12 - 21:58:57]<willikins>	Whissi: https://bugs.gentoo.org/542498 "Retire: NP Hardass (np-hardass)"; Gentoo Developers/Staff, Retirement; CONF; idella4:retirement
[2019-05-12 - 21:59:35]<ulm>		why is council in cc there? was there an appeal?
[2019-05-12 - 21:59:43]<Whissi>		NP-Hardass: Want to say something to explain council what you want from us?
[2019-05-12 - 21:59:49]<mgorny>		there was no appeal since there were no retirement yet
[2019-05-12 - 21:59:57]<NP-Hardass>	Yeah, recruiters is moving ahead for reitrement
[2019-05-12 - 22:00:03]<NP-Hardass>	I have activity on the books
[2019-05-12 - 22:00:24]<NP-Hardass>	So, I was pre-emptively appealing to the council to stop undertakers from moving ahead
[2019-05-12 - 22:01:00]<NP-Hardass>	I've authored ~30 commits touching almost that many packages since last council meeting
[2019-05-12 - 22:01:08]<K_F>		NP-Hardass: if staying on as a non-committing dev I'd recommend finding some project to join related to it
[2019-05-12 - 22:01:26]<NP-Hardass>	K_F: I'm lead on a project, and member to another
[2019-05-12 - 22:01:39]<gokturk>	K_F: I proxy his commits, so he's able to actively contribute code
[2019-05-12 - 22:01:55]<K_F>		gokturk: right, but he doesn't need to be dev for that per se
[2019-05-12 - 22:01:59]<leio>		I think it makes sense to remove his commit bit.
[2019-05-12 - 22:02:17]<gokturk>	K_F: being a dev also gives him power to steer projects that he's a lead of
[2019-05-12 - 22:02:18]<K_F>		gokturk: so if not a committing dev he should stay on as a non-commiting dev (prev staffer)
[2019-05-12 - 22:02:40]<K_F>		leio: that part is done already, thats not in question
[2019-05-12 - 22:02:48]<WilliamH>	I guess the question is, do you have to be a committing dev to be a lead?
[2019-05-12 - 22:02:52]<gokturk>	K_F: he is unable to commit due to a policy issue. policies change.
[2019-05-12 - 22:03:19]*		mgorny doesn't see why he should have additional privileges over other proxied maintainers
[2019-05-12 - 22:03:24]<mgorny>		this is plainly unfair to others
[2019-05-12 - 22:03:27]<NP-Hardass>	Just as a side note...   when a driver gets a drivers license... they are entitled to drive... if the govt passes a law saying no driving on wednesday, the driver doesn't lose their license.    Likewise, I earned the right to be a full developer, and while *policy* prevents me from commiting, logicaly, I should retain all dev rights
[2019-05-12 - 22:03:29]<K_F>		its my 2c anyways, I don't see any reason to deviate from established policies
[2019-05-12 - 22:03:41]<zlogene>	WilliamH: I'd say "do the person need a status if they can't commit and not are security/infra/forums staffer"
[2019-05-12 - 22:03:56]<ulm>		mgorny: he has done the quizzes, while other proxied maintainers haven't
[2019-05-12 - 22:03:59]<NP-Hardass>	Now, I can understand if you think they should remove the commit bit if only to align with the policy, but really, nothing else should change
[2019-05-12 - 22:04:16]<leio>		ok, I see the commit bit is already gone, sorry for confusion.
[2019-05-12 - 22:04:21]<NP-Hardass>	Done the quizzes, and interviews.  I earned my position as a developer
[2019-05-12 - 22:04:25]<gokturk>	K_F: keeping him as a dev leaves room for the possibility in the future that he may be able to commit again
[2019-05-12 - 22:04:51]<mgorny>		NP-Hardass: with your recent behavior, i dare say you lost any claims to it
[2019-05-12 - 22:04:53]<leio>		but the confusion comes from the bug discussion and debates about whether commits are developer contributions
[2019-05-12 - 22:05:05]<NP-Hardass>	mgorny: what recent behavior?
[2019-05-12 - 22:05:11]<NP-Hardass>	Please.... elaborate
[2019-05-12 - 22:05:21]<mgorny>		the behavior of attacking recruiters rather than talking to us
[2019-05-12 - 22:05:29]<mgorny>		er, undertakers
[2019-05-12 - 22:05:42]<NP-Hardass>	I merely stated that I was ignored when I reached out to recruiters
[2019-05-12 - 22:05:52]<K_F>		gokturk: sure, but its possible to re-join in principle. In any case, I recommend finding a role in a project not requiring commit rights
[2019-05-12 - 22:06:07]<NP-Hardass>	And that the retirement process moving forward, ignoring that, was abusive.  That's not attacking.
[2019-05-12 - 22:06:07]<Whissi>		K_F: He is leading a project...
[2019-05-12 - 22:06:10]<mgorny>		NP-Hardass: you didn't have any activity between the mails
[2019-05-12 - 22:06:12]<zlogene>	NP-Hardass: excuse me? How are recruiters relevant here?
[2019-05-12 - 22:06:30]<NP-Hardass>	zlogene: s/recruiters/undertakers/
[2019-05-12 - 22:06:52]<mgorny>		let me put it like this
[2019-05-12 - 22:07:02]<mgorny>		if NP-Hardass is going to be staffer while his only activity is providing commits
[2019-05-12 - 22:07:07]<gokturk>	K_F: I understand that but it's hardly an argument for taking someone else's dev rights. he can't commit until the policy changes anyway. so there's hardly any gain in changing his status.
[2019-05-12 - 22:07:14]<mgorny>		then it creates a fair case for a lot of proxied maintainers to become staffers
[2019-05-12 - 22:07:29]<leio>		there is no such thing as a staffer
[2019-05-12 - 22:07:32]<NP-Hardass>	mgorny: have those proxied maintainers taken quizzes and passed the interviews?
[2019-05-12 - 22:07:34]<NP-Hardass>	nno
[2019-05-12 - 22:07:41]<mgorny>		including people who are never going to commit (as we need to presume will be the case with np-hardass)
[2019-05-12 - 22:07:41]<gokturk>	mgorny: proxied maintainers **can** become staffers by doing the quizzes etc. just like any other dev ...
[2019-05-12 - 22:07:47]<Whissi>		Don't we allow/want people without commit bit anymore? Has this changed?
[2019-05-12 - 22:07:55]<mgorny>		NP-Hardass: they didn't because there is no reason why they would
[2019-05-12 - 22:08:08]<mgorny>		having dev status with no commit bit is just pointless
[2019-05-12 - 22:08:19]<mgorny>		no offense but it is just wasted time for recruiters
[2019-05-12 - 22:08:33]<gokturk>	I disagree. Devs still have the power to vote for the council members, run for the council, lead projects etc.
[2019-05-12 - 22:08:36]<K_F>		that part is within existing policy
[2019-05-12 - 22:08:49]<zlogene>	Whissi: we do, but if the person is notr involved in any staff work, what happens is just peoxy maintaince work
[2019-05-12 - 22:08:56]<mgorny>		gokturk: so basically we should create a major number of devs who don't do anything, and rule gentoo?
[2019-05-12 - 22:09:16]<gokturk>	I just pushed 27 commits from him prior to this meeting
[2019-05-12 - 22:09:21]<gokturk>	he is contributing code
[2019-05-12 - 22:09:28]<gokturk>	I don't know why we are portraying him as someone who does nothing
[2019-05-12 - 22:09:29]<WilliamH>	mgorny: Have all of those proxy maintainers taken the quizzes, passed the recruitment interviews etc?
[2019-05-12 - 22:09:49]<mgorny>		WilliamH: as i said, that would be wasting recruiters time
[2019-05-12 - 22:09:56]<NP-Hardass>	WilliamH: in other words, no
[2019-05-12 - 22:10:05]<mgorny>		gpm never encouraged joining as non-committing devs
[2019-05-12 - 22:10:16]<ulm>		mgorny: do undertakers have word from projects about his activity?
[2019-05-12 - 22:10:21]<gokturk>	I think gpm is irrevelant to the discussion ...
[2019-05-12 - 22:10:29]<mgorny>		ulm: no
[2019-05-12 - 22:10:34]<WilliamH>	mgorny: I've seen a proxy maintainer claim to be the primary maintainer of a package over me, and it was allowed.
[2019-05-12 - 22:10:45]<NP-Hardass>	ulm: at the time undertakers started moving forward, I was lead of two projects
[2019-05-12 - 22:10:51]<NP-Hardass>	they did not reach out to either
[2019-05-12 - 22:11:03]<mgorny>		WilliamH: if someone is causing problems, you should have contacted the team rather than bringing this up now
[2019-05-12 - 22:11:06]<ulm>		mgorny: no in the sense of no activity, or no word?
[2019-05-12 - 22:11:26]<mgorny>		ulm: no word. he didn't formally enlist in any staffing projects afaik
[2019-05-12 - 22:11:39]<mgorny>		instead, he choose to attack us, and request comrel and council intervention
[2019-05-12 - 22:11:39]<dilfridge>	what's a staffing project?
[2019-05-12 - 22:11:44]<NP-Hardass>	My two projects were not contacted by undertakers to ascertain any involvement by me
[2019-05-12 - 22:11:47]<dilfridge>	mgorny: ^
[2019-05-12 - 22:11:48]<mgorny>		he didn't even inform us of his activity beforehand
[2019-05-12 - 22:12:09]<WilliamH>	mgorny: Did he inform you when you sent out the retirement emails?
[2019-05-12 - 22:12:09]<mgorny>		dilfridge: i meant a project that enlists a staffer
[2019-05-12 - 22:12:30]<mgorny>		WilliamH: his only reply was from December last year, which stated 'he is working on it'
[2019-05-12 - 22:12:30]<leio>		again, there is no such thing as a staffer. There are developers; some have gentoo.git push access, others don't.
[2019-05-12 - 22:12:40]<dilfridge>	does any project *not* do that? also, there are no staffers.
[2019-05-12 - 22:12:46]<mgorny>		at that point and 2nd mail point he had no measurable activity
[2019-05-12 - 22:13:18]<mgorny>		at 3rd mail point he went straight for comrel rather than informing us there's an activity via proxy
[2019-05-12 - 22:13:27]<WilliamH>	So, there are devs with no commit access  leio?
[2019-05-12 - 22:13:27]<ulm>		mgorny: IIU undertakers policy C, you should ask leads of the projects listed in https://wiki.gentoo.org/wiki/User:NP-Hardass ?
[2019-05-12 - 22:13:36]<NP-Hardass>	WilliamH: the process for the retirement emails went as follows.  first email received, I responded saying glep 76 prevented me.   then I received a 2nd email indicating I was closer to retirement.  I never once heard back from undertakers on the original email, so I posted to my devbug.  That was not responded to.  The 3rd email was sent indicating I was in imminent danger of being retired, so I
[2019-05-12 - 22:13:37]<leio>		WilliamH: Yes.
[2019-05-12 - 22:13:38]<NP-Hardass>	brought you guys in
[2019-05-12 - 22:14:00]*		NeddySeagoon ha no commit access
[2019-05-12 - 22:14:21]<mgorny>		ulm: those are all committing projects
[2019-05-12 - 22:14:25]<leio>		well, I could nitpick you do have commit access, you just don't have push access ;)
[2019-05-12 - 22:14:28]<mgorny>		why would we ask for staffer activity there?
[2019-05-12 - 22:14:28]<NP-Hardass>	If there have been any attempts by undertakers to ascertain my activity, never once was I spoken to
[2019-05-12 - 22:14:38]<NP-Hardass>	even as I was lead for 2 projects
[2019-05-12 - 22:14:54]<NP-Hardass>	plain and simple, undertakers moved forward without due diligence
[2019-05-12 - 22:14:58]<WilliamH>	mgorny: As leio said, there are devs that don't have commit access.
[2019-05-12 - 22:15:02]<leio>		please repeat after me. There is no such position within Gentoo called "staffer".
[2019-05-12 - 22:15:07]<mgorny>		NP-Hardass: so you're saying that if a dev creates project, becomes its lead, he can not do anything because he can say he's active in the project he maintains himself?
[2019-05-12 - 22:15:10]<dilfridge>	again what is a committing project? I would be happy to have a dev without push access do research on toolchain issues for me...
[2019-05-12 - 22:15:31]<WilliamH>	Commit access isn't required to be a dev mgorny
[2019-05-12 - 22:15:34]<NP-Hardass>	mgorny: I am saying that undertakers is supposed to reach out to projects that a dev is involved in.  And they did not (period)
[2019-05-12 - 22:15:38]<zlogene>	dilfridge: I though you have hamsters for that...
[2019-05-12 - 22:15:40]<mgorny>		WilliamH, leio: could we please grow up and not nitpick names? 'staffer' is shorter to type, it's 15 mintues past midinght and i'm waking up in 4 hours
[2019-05-12 - 22:16:05]<dilfridge>	zlogene: don't tempt me to paste youtube links
[2019-05-12 - 22:16:08]<mgorny>		NP-Hardass: undertakers reach to projects based on roles
[2019-05-12 - 22:16:12]<leio>		Your naming implies all the following; that there must be activity in a staffer project (what is that?) and so on
[2019-05-12 - 22:16:23]<mgorny>		if you don't inform us which projects to contact, don't expect us to go out of our way to prove you're active
[2019-05-12 - 22:16:25]<mgorny>		that's your job
[2019-05-12 - 22:16:29]<leio>		And I do not appreciate your tone at this point.
[2019-05-12 - 22:16:38]<dilfridge>	zlogene: when we finally voted for the QA glep change, I was *this* close to the Harry&Sally scene...
[2019-05-12 - 22:16:42]<WilliamH>	mgorny: you should be able to find the projects on the wiki.
[2019-05-12 - 22:16:49]<mgorny>		leio: and i don't appreciate yours but we have to live with each other, at least till the next council election
[2019-05-12 - 22:17:00]<mgorny>		let me get this clear
[2019-05-12 - 22:17:05]<mgorny>		we have two classes of devs
[2019-05-12 - 22:17:12]<WilliamH>	mgorny: no we don't.
[2019-05-12 - 22:17:14]<gokturk>	NP was unable to commit due to GLEP 76 issues. shortly after that was addressed he started committing via proxy. he is attending a council meeting to state that he's active. shouldn't this eliminate any existing doubts about his activity already?
[2019-05-12 - 22:17:16]<mgorny>		devs with commit access are verified by their commit activity
[2019-05-12 - 22:17:33]<mgorny>		devs without are verified based on projects like forums, security
[2019-05-12 - 22:17:44]<WilliamH>	mgorny: and bugzilla activity?
[2019-05-12 - 22:17:44]<zlogene>	dilfridge: that feel when 8 years (since 2011?) gentoo qa drama is over?
[2019-05-12 - 22:17:47]<mgorny>		NP-Hardass is not on any of such projects afaik
[2019-05-12 - 22:18:10]<gokturk>	mgorny: and now you have a dev whose activity should be measured by his commit activity via proxy
[2019-05-12 - 22:18:11]<mgorny>		WilliamH: bugzilla activity is part of committing dev action
[2019-05-12 - 22:18:25]<mgorny>		gokturk: please get official policy on this
[2019-05-12 - 22:18:25]<ulm>		I don't see anything in glep 39 about "committing projects"
[2019-05-12 - 22:18:36]<WilliamH>	ulm++
[2019-05-12 - 22:18:53]<mgorny>		this is not how recruiters worked
[2019-05-12 - 22:18:59]<gokturk>	mgorny: since you've declared undertakers policy to not be a policy 3 days ago (https://wiki.gentoo.org/index.php?title=Project:Undertakers&diff=801365&oldid=734778), I don't know where to look
[2019-05-12 - 22:19:37]<mgorny>		it's funny how people claim something i wrote without any review to be a policy when it's convenient to them
[2019-05-12 - 22:19:56]<mgorny>		if i wrote there that np-hardass must be retired as a policy, it suddenly wouldn't be considered a policy
[2019-05-12 - 22:20:19]<NP-Hardass>	At the time that retirement proceedings started, that page detailed a policy
[2019-05-12 - 22:20:29]<NP-Hardass>	if you change it after the fact, that's irrelevant
[2019-05-12 - 22:20:37]<mgorny>		gokturk: in other words, i've merely corrected the mistaken interpretation of what i wrote earlier on that page *without review*
[2019-05-12 - 22:20:51]<mgorny>		it was my mistake, and i corrected it
[2019-05-12 - 22:21:24]<Whissi>		OK. Maybe we can move on and talk about what's NEXT: Can NP-Hardass stay as staffer or dev without commit bit however you would like to name it? Or is there a policy saying "No, you need commit bit..."
[2019-05-12 - 22:21:26]<mgorny>		NP-Hardass: so what's your saying is that if i put some text on undertakers page, it instantly becomes a policy? without any formal review, vote or anything?
[2019-05-12 - 22:21:59]<NP-Hardass>	Whissi: there is only whether undertakers decides for some reason that I can't be a dev because I can't commit, which is what they are trying to do
[2019-05-12 - 22:22:00]<K_F>		Whissi: yes thats definitely possible in current structure
[2019-05-12 - 22:22:19]<K_F>		and as long as sufficient contributions are being made one way or the other, there aren't really reasons to retire
[2019-05-12 - 22:22:37]<Whissi>		So if this is possible, NP-Hardass will likely lose commit bit but undertaker will stop. Can we agree on this and move on?
[2019-05-12 - 22:22:38]<gokturk>	K_F++
[2019-05-12 - 22:22:41]<ulm>		I tend to agree, if there's some way to verify that he's active
[2019-05-12 - 22:22:50]<mgorny>		K_F: does that mean we have to accept proxied maintainers after they do the general quiz?
[2019-05-12 - 22:22:59]<NP-Hardass>	ulm: author field of commits
[2019-05-12 - 22:23:13]<mgorny>		iow, add a lot of work on recruiters for people who will still require work of another dev to actually contribute?
[2019-05-12 - 22:23:18]<WilliamH>	mgorny: Ideally, if they do all of the quizzes, they become devs.
[2019-05-12 - 22:23:28]<K_F>		mgorny: "have to" is a bit odd, we don't have to do anything per se.. but I'm not really sure which scenario you're worried about
[2019-05-12 - 22:23:39]<WilliamH>	Yeah I'm not sure either mgorny
[2019-05-12 - 22:23:50]<mgorny>		i'm worried about a lot of effort (because recruiting is a lot of effort)
[2019-05-12 - 22:23:52]<ulm>		WilliamH: quizzes and interviews
[2019-05-12 - 22:23:55]<K_F>		but no, quizzes can not be only requirement
[2019-05-12 - 22:24:00]<WilliamH>	ulm: Sure. :-)
[2019-05-12 - 22:24:07]<gokturk>	I did recruit people, I'm not sure what the worry is
[2019-05-12 - 22:24:08]<mgorny>		with negligible gain (because dev or not, proxied maintainer still needs another dev to commit)
[2019-05-12 - 22:24:10]<K_F>		so they would need to demonstrate contributions and regular interviews etc
[2019-05-12 - 22:24:19]<NP-Hardass>	ulm: current recruiter scripts scrap commit field IIRC.  so, author field shouldn't be too complicated, I think
[2019-05-12 - 22:24:20]<WilliamH>	K_F:   Sure.
[2019-05-12 - 22:24:40]<mgorny>		one more question, on a related topic
[2019-05-12 - 22:24:50]<mgorny>		say, if np-hardass makes qa violations
[2019-05-12 - 22:24:51]<NP-Hardass>	s/scrap/scrape/
[2019-05-12 - 22:25:11]<mgorny>		should he get banned or his proxy?
[2019-05-12 - 22:25:15]<K_F>		mgorny: proxy committer has review responsibility, so that could hit the one proxying
[2019-05-12 - 22:25:21]<gokturk>	I take responsibility for proxying him
[2019-05-12 - 22:25:30]<WilliamH>	mgorny: that's not really a relevant topic, because others are proxying NP-Hardass' commits.
[2019-05-12 - 22:25:50]<WilliamH>	In theory those should be caught before they get in the tree.
[2019-05-12 - 22:26:07]<WilliamH>	That's the same thing we do for any proxied commits right?
[2019-05-12 - 22:26:19]<mgorny>		for other proxied commits, yes
[2019-05-12 - 22:26:31]<mgorny>		but since the proxied person is a dev with ebuild quizzes, i'm not sure if this really happens here
[2019-05-12 - 22:26:42]<mgorny>		or people just assume it's fine and push it
[2019-05-12 - 22:26:48]<dilfridge>	shouldnt that be the worry of who is proxying him?
[2019-05-12 - 22:26:56]<WilliamH>	mgorny: That would be the fault of the proxying dev in any case.
[2019-05-12 - 22:27:04]<mgorny>		ok
[2019-05-12 - 22:27:54]<Whissi>		OK. Vote: Undertaker should stop retirement of NP-Hardass (bug https://bugs.gentoo.org/542498) as long as NP-Hardass shows *any* activity like former staffer or dev in Gentoo. Yes/No
[2019-05-12 - 22:28:06]*		WilliamH yes
[2019-05-12 - 22:28:09]*		Whissi yes
[2019-05-12 - 22:28:17]*		ulm yes
[2019-05-12 - 22:28:19]*		K_F yes
[2019-05-12 - 22:28:28]<mgorny>		didn't council used to have a policy that items not on agenda shouldn't be voted on?
[2019-05-12 - 22:28:50]<WilliamH>	let's move on...
[2019-05-12 - 22:28:52]*		dilfridge yes
[2019-05-12 - 22:28:58]*		slyfox yes
[2019-05-12 - 22:29:08]<ulm>		ultimately this boils down on how we treat our devs
[2019-05-12 - 22:29:14]*		leio yes
[2019-05-12 - 22:29:25]<Whissi>		Motion passed. I'll update bug later and let undertaker know...
[2019-05-12 - 22:29:36]<dilfridge>	ulm++
[2019-05-12 - 22:29:39]<ulm>		unanimous even
[2019-05-12 - 22:29:45]<NP-Hardass>	Thank you!
[2019-05-12 - 22:30:13]<Whissi>		mgorny: for the records, this is topic #6 and bug is listed in council bug query.
[2019-05-12 - 22:30:42]<Whissi>		Next, bug 662982
[2019-05-12 - 22:30:44]<willikins>	Whissi: https://bugs.gentoo.org/662982 "[TRACKER] New default locations for the Gentoo repository, distfiles, and binary packages"; Gentoo Linux, Current packages; CONF; zmedico:dev-portage
[2019-05-12 - 22:30:52]<K_F>		N/A
[2019-05-12 - 22:31:00]<Whissi>		Just a status update:
[2019-05-12 - 22:31:05]<mgorny>		so if you don't make it in time for agenda, you can file a bug and you can avoid public discusson on it
[2019-05-12 - 22:31:41]<K_F>		mgorny: depends on the severity / time limits involved / whatever...
[2019-05-12 - 22:31:46]<WilliamH>	mgorny: This was in the council bug query before the agenda went out right?
[2019-05-12 - 22:31:54]<ulm>		WilliamH: yes
[2019-05-12 - 22:31:56]<ulm>		it was
[2019-05-12 - 22:32:08]<Whissi>		We still need to update tools. Infra worked on new file locations but we also need a transition phase.
[2019-05-12 - 22:32:48]<ulm>		we keep council in cc?
[2019-05-12 - 22:33:02]<Whissi>		I hope to revisit bug this week to define blockers so we can move on if something is not _required_ to let this happen.
[2019-05-12 - 22:33:22]<Whissi>		I would say yes because council decided on that change but change hasn't happened. So we need to track...
[2019-05-12 - 22:34:02]<ulm>		k
[2019-05-12 - 22:34:06]<Whissi>		Questions or can I move on to next bug?
[2019-05-12 - 22:34:21]<K_F>		next
[2019-05-12 - 22:34:33]<dilfridge>	next();
[2019-05-12 - 22:34:36]<Whissi>		Bug 684192:  Motion passed in this meeting
[2019-05-12 - 22:34:38]<willikins>	Whissi: https://bugs.gentoo.org/684192 "glep-0048: Disciplinary action update"; Documentation, GLEP Changes; CONF; mgorny:council
[2019-05-12 - 22:34:45]<Whissi>		Bug 677824
[2019-05-12 - 22:34:47]<willikins>	Whissi: https://bugs.gentoo.org/677824 "Deferred decision: Forums (specifically OTW)"; Gentoo Council, unspecified; CONF; k_f:council
[2019-05-12 - 22:34:53]<dilfridge>	oh fun
[2019-05-12 - 22:35:06]<Whissi>		I would recommend to close unless someone wants to start this again.
[2019-05-12 - 22:35:11]<K_F>		I can bring that one up for ML again during next week
[2019-05-12 - 22:35:22]<Whissi>		Mh.. OK.
[2019-05-12 - 22:35:23]<WilliamH>	K_F: go for it.
[2019-05-12 - 22:35:50]<Whissi>		Bug 684170
[2019-05-12 - 22:35:52]<willikins>	Whissi: https://bugs.gentoo.org/684170 "Copyright policy: should we require working (delivering) e-mail addresses?"; Gentoo Council, unspecified; CONF; mgorny:council
[2019-05-12 - 22:36:20]<K_F>		we don't really have any way to verify it, so seems like over-engineering
[2019-05-12 - 22:36:30]<WilliamH>	K_F++
[2019-05-12 - 22:36:33]<K_F>		but at same time I'd say we shouldn't deliberately use non-deliverale addresses
[2019-05-12 - 22:36:38]<dilfridge>	it's another case of "apply common sense"
[2019-05-12 - 22:36:40]<dilfridge>	yes
[2019-05-12 - 22:36:47]<K_F>		exactly
[2019-05-12 - 22:36:49]<WilliamH>	dilfridge++
[2019-05-12 - 22:36:50]<Whissi>		Agreed.
[2019-05-12 - 22:37:02]<ulm>		+1
[2019-05-12 - 22:37:27]<dilfridge>	"you should use a working e-mail address, and we're going to be annoyed if you try to use president@whitehouse.gov"
[2019-05-12 - 22:37:30]<mgorny>		ftr, this was triggered by someone actually using explicitly non-deliverable address?
[2019-05-12 - 22:37:38]<mgorny>		s/\?//
[2019-05-12 - 22:37:52]<dilfridge>	yeah and that makes no sense
[2019-05-12 - 22:38:14]<WilliamH>	This is just a case of common sense, should we really have to write it into policy?
[2019-05-12 - 22:38:17]<Whissi>		If you spot something like that, ask to stop. But don't start a hunt...
[2019-05-12 - 22:38:20]<ulm>		RESO USECOMMONSENSEANDDONTBESTUPID
[2019-05-12 - 22:39:03]<WilliamH>	ulm:  lol
[2019-05-12 - 22:39:07]<Whissi>		ulm: Do we have to ask infra to add that resolution first?
[2019-05-12 - 22:39:17]<ulm>		:)
[2019-05-12 - 22:39:31]<dilfridge>	then I want RESOLVED PEBKAC too
[2019-05-12 - 22:40:29]<Whissi>		Do I need to start a formal vote?
[2019-05-12 - 22:40:36]<WilliamH>	no
[2019-05-12 - 22:40:46]<dilfridge>	0
[2019-05-12 - 22:40:47]<ulm>		no, move on
[2019-05-12 - 22:40:49]<WilliamH>	let's move on.
[2019-05-12 - 22:40:54]<Whissi>		bug 676248
[2019-05-12 - 22:40:56]<willikins>	Whissi: https://bugs.gentoo.org/676248 "non-free licenses are accepted without user prompt"; Gentoo Linux, Profiles; CONF; whissi:licenses
[2019-05-12 - 22:41:10]*		mgorny supposes he's not needed anymore
[2019-05-12 - 22:41:11]<mgorny>		good night
[2019-05-12 - 22:41:12]<WilliamH>	I think this is fixed.
[2019-05-12 - 22:41:13]<ulm>		I'm still waiting for an ack from releng
[2019-05-12 - 22:41:19]<WilliamH>	ah ok.
[2019-05-12 - 22:41:44]<ulm>		the alternative would be to flip the switch and let releng sort out any breakage
[2019-05-12 - 22:41:59]<ulm>		but maybe that wouldn't be so friendly
[2019-05-12 - 22:42:03]<WilliamH>	tbh I would be ok with that.
[2019-05-12 - 22:42:04]<dilfridge>	flip it
[2019-05-12 - 22:42:26]<dilfridge>	jmbsvicetto said a few times that it should be ok
[2019-05-12 - 22:42:27]<K_F>		it has been notified about for a long time already, so I'm actually fine with it
[2019-05-12 - 22:42:34]<Whissi>		Let's ping releng and do it later this week if no response.
[2019-05-12 - 22:42:52]<Whissi>		2 more days don't count
[2019-05-12 - 22:42:52]<ulm>		Whissi: I just was going to say that :)
[2019-05-12 - 22:42:57]<leio>		lets try to not throw potential breakage at users, but if they think reasonably well that it'll be fine...
[2019-05-12 - 22:43:38]<ulm>		stages should be fine as is, and the course of action for install cds is clear
[2019-05-12 - 22:44:02]<ulm>		and AFAICS there shouldn't be major blockers
[2019-05-12 - 22:44:05]<Whissi>		If we will get aware of a major problem we always can flip back
[2019-05-12 - 22:44:13]<dilfridge>	flop
[2019-05-12 - 22:44:18]<Whissi>		:)
[2019-05-12 - 22:44:25]<WilliamH>	;-)
[2019-05-12 - 22:44:31]<Whissi>		Bug 679250: OK for marking GLEP 79 final?
[2019-05-12 - 22:44:33]<willikins>	Whissi: https://bugs.gentoo.org/679250 "GLEP 79: Gentoo OpenPGP Authority Keys"; Documentation, New GLEP submissions; IN_P; mgorny:glep
[2019-05-12 - 22:44:52]<dilfridge>	why not
[2019-05-12 - 22:45:17]<K_F>		wfm
[2019-05-12 - 22:45:26]*		ulm yes
[2019-05-12 - 22:45:32]*		dilfridge yes
[2019-05-12 - 22:45:34]*		leio yes
[2019-05-12 - 22:45:38]*		slyfox yes
[2019-05-12 - 22:45:41]*		Whissi yes
[2019-05-12 - 22:45:47]*		K_F yes
[2019-05-12 - 22:46:12]*		WilliamH yes
[2019-05-12 - 22:46:21]<Whissi>		Motion passed.
[2019-05-12 - 22:46:38]<Whissi>		Bug 642072
[2019-05-12 - 22:46:40]<willikins>	Whissi: https://bugs.gentoo.org/642072 "[Tracker] Copyright policy"; Gentoo Council, unspecified; IN_P; mgorny:council
[2019-05-12 - 22:46:43]<Whissi>		Only tracker, right?
[2019-05-12 - 22:46:53]<slyfox>		yes
[2019-05-12 - 22:47:17]<Whissi>		Bug 637328
[2019-05-12 - 22:47:19]<willikins>	Whissi: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; IN_P; mgorny:security
[2019-05-12 - 22:47:33]<Whissi>		Security project actually started to work on this :p
[2019-05-12 - 22:47:58]<slyfox>		any update since last meeting? :)
[2019-05-12 - 22:47:58]<K_F>		i.e re-started again
[2019-05-12 - 22:48:10]<Whissi>		Nothing more to add for now.
[2019-05-12 - 22:48:28]<Whissi>		That's it. We are moving to open floor
[2019-05-12 - 22:48:28]<leio>		does it really need to be in the private confines of security@ mail alias still?
[2019-05-12 - 22:48:33]*		Whissi removes ban on veremitz!*@*
[2019-05-12 - 22:49:01]<Whissi>		leio: We are drafting. Once security project has something we all agree on, we will make it public
[2019-05-12 - 22:49:03]<K_F>		leio: the last round was sent out in public ML
[2019-05-12 - 22:49:07]*		WilliamH has something for open floor
[2019-05-12 - 22:49:30]<K_F>		then it went back to private discussions again.. when its ready it will be sent out for comment
[2019-05-12 - 22:49:36]<leio>		ah, right, I remember something. Can you link to the archive on the bug?
[2019-05-12 - 22:49:50]<Whissi>		The draft was withdrawn. We are working on something new.
[2019-05-12 - 22:49:54]<leio>		ok..
[2019-05-12 - 22:50:06]<WilliamH>	While verimitz's behaviour might have been inappropriate during the meeting, any action against him should have been taken by the meeting chair.
[2019-05-12 - 22:50:32]<WilliamH>	I request that we vote to censure dilfridge for his action in this situation.
[2019-05-12 - 22:51:23]<WilliamH>	All a censure is is an expression of strong disapprooval.
[2019-05-12 - 22:51:26]<jmbsvicetto>	dilfridge: as was tracked by ulm, there should be no issues with the stages. The isos / stage4 will break with the change, though
[2019-05-12 - 22:51:47]<jmbsvicetto>	dilfridge: I've been meaning to run some tests locally to test the required change to catalyst, but I unfortunately wasn't able to get to it yet
[2019-05-12 - 22:52:22]<K_F>		WilliamH: although I agree on the principle, there is no need to over-react to it either
[2019-05-12 - 22:52:33]<K_F>		i.e principle of chair being only one banning/kicking
[2019-05-12 - 22:52:38]<ulm>		for the record, https://projects.gentoo.org/council/meeting-logs/20171210-summary.txt
[2019-05-12 - 22:52:53]<ulm>		"The council agrees that kicking and moderation should be restricted to the meeting chair for the duration of a council meeting."
[2019-05-12 - 22:53:21]<ulm>		but also I'm with K_F
[2019-05-12 - 22:53:50]<Whissi>		I wasn't aware about such a 'rule'.
[2019-05-12 - 22:54:06]<ulm>		jmbsvicetto: any ETA?
[2019-05-12 - 22:54:16]<K_F>		Whissi: chair's responsibility to keep order..
[2019-05-12 - 22:54:19]<WilliamH>	How is expressing disaprooval formally overreacting?
[2019-05-12 - 22:54:34]<WilliamH>	grr I can't type :p
[2019-05-12 - 22:55:14]<K_F>		WilliamH: its wasting time , point has been made already
[2019-05-12 - 22:55:18]<ulm>		WilliamH: it's a call to order, and it's up to the chair
[2019-05-12 - 22:55:32]<ulm>		but not a subject for a vote, IMHO
[2019-05-12 - 22:55:33]<NeddySeagoon>	WilliamH: Its like this, dilfridge gets a pat on the back for the result and a slap on the wrist for the method.
[2019-05-12 - 22:55:42]<Whissi>		WilliamH: Would you accept an excuse from dilfridge (ofc, only in case he actually wants to apologize) or do you want to vote on official censure call?
[2019-05-12 - 22:56:04]<WilliamH>	I would accept one. Sure.
[2019-05-12 - 22:56:11]<Whissi>		dilfridge?
[2019-05-12 - 22:57:13]<dilfridge>	WilliamH: I'm happy to admit that this was outside of agreed-upon rules.
[2019-05-12 - 22:57:33]<dilfridge>	If you think this needs an apology, then here it is.
[2019-05-12 - 22:57:57]<WilliamH>	ok. That's fwm.
[2019-05-12 - 22:58:04]<Whissi>		Good.
[2019-05-12 - 22:58:30]<Whissi>		Has anyone else something to discuss?
[2019-05-12 - 22:58:52]<dilfridge>	next time earlier please
[2019-05-12 - 22:59:14]<Whissi>		I expect next meeting at regular time, yes.
[2019-05-12 - 22:59:15]<K_F>		dilfridge: yeah, it was a one off so I could get back from Paris :)
[2019-05-12 - 22:59:28]<gokturk>	I would like to express concern for the undertakers policy change I previously mentioned
[2019-05-12 - 22:59:53]<jmbsvicetto>	ulm: if the approval was to flip it this week, I'd like to ask you wait at most until next weekend
[2019-05-12 - 22:59:57]<gokturk>	it gives the impression that even an actively committing dev could be considered inactive by the undertakers
[2019-05-12 - 23:00:02]<jmbsvicetto>	ulm: I'll do my best to get to it tomorrow
[2019-05-12 - 23:00:15]<K_F>		gokturk: too broad topic for open floor really , should bring it to ML
[2019-05-12 - 23:00:27]<gokturk>	K_F: ack. thanks.
[2019-05-12 - 23:00:37]<WilliamH>	Yeah we could bikeshed that forever gokturk  ;-)
[2019-05-12 - 23:00:55]<ulm>		jmbsvicetto: I'll note 2019-05-19 as the date for the switch, are you fine with that?
[2019-05-12 - 23:01:10]*		WilliamH needs to take off ;-)
[2019-05-12 - 23:01:21]*		Shentino (~shentino@unaffiliated/shentino) has joined
[2019-05-12 - 23:01:35]<jmbsvicetto>	ulm: sure, thanks
[2019-05-12 - 23:01:40]<Whissi>		Thank you all for participating. I am closing the 188th council meeting.