Add log for 2019-04-14 meeting

Signed-off-by: William Hubbs <williamh@gentoo.org>

2 files changed, 604 insertions, 0 deletions

diff --git a/meeting-logs/20190414.txt b/meeting-logs/20190414.txt
new file mode 100644
index 0000000..0085689
--- /dev/null
+++ b/meeting-logs/20190414.txt
@@ -0,0 +1,588 @@
+14:01 <@WilliamH> Ok folks, let's get started.
+14:01 <@WilliamH> agenda: https://archives.gentoo.org/gentoo-project/message/81126506f08d0f11c5a6d4c0c459baf5
+14:01 <@WilliamH> 1. Roll Call:
+14:01  * leio here
+14:01  * K_F here
+14:01  * Whissi here
+14:02  * WilliamH here
+14:02  * ulm here
+14:02 <@WilliamH> We're missing 2.
+14:02 <@Whissi> !proj council
+14:02 <+willikins> Whissi: (council@gentoo.org) dilfridge, k_f, leio, slyfox, ulm, whissi, williamh
+14:02 <@K_F> iirc slyfox mentioned not being able to join, but I haven't seen any proxy announcement
+14:02 <@dilfridge> yabba dabba dooo
+14:02  * dilfridge here
+14:03 <@WilliamH> and dilfridge?
+14:03 <@WilliamH> heh
+14:03 <@WilliamH> ok
+14:03 <@WilliamH> 2. glep 80:
+14:03 <@K_F> on a general note, I don't see this belonging as a GLEP as it is optional and very informative in nature, wiki page seems like a better place for it
+14:04 <@WilliamH> Yeah probably.
+14:04 <@K_F> basically a versioned certification policy URI that can be used by anyone
+14:04 <@WilliamH> Since it is just informative, I don't see that it needs to be a glep.
+14:04 <@Whissi> ACK. But if this should be linked in policy, you need a fixed URL... not a wiki.
+14:04 <@ulm> K_F: I had told mgorny that it should be of Informational type
+14:04 <@dilfridge> it's nice and useful, but not really a central issue for us
+14:05 <@K_F> if anyone wants to write a recommendation it can be anywhere, really
+14:05 <@WilliamH> K_F++
+14:05 <@ulm> K_F: his reason for making it Standards Track was that it contains its own address as policy url
+14:05 <@ulm> --cert-policy-url
+14:06 <@K_F> ulm: well, if the policy is published , that is really RFC4880 to handle as you use it when signing anyways
+14:06 <@K_F> it doesn't need a standard track for Gentoo
+14:06 <@K_F> the people opting in to use the policy can do it
+14:06 <+mgorny> Having it a glep makes it stable
+14:06 <@Whissi> The question is if we, Gentoo, want to provide something which could be used like a policy.
+14:07 <@dilfridge> meh, in my opinion this can be a glep, but I dont feel strongly either way
+14:07 <@Whissi> In this case we need a stable URL.
+14:07 <@K_F> now, an argument could be that Gentoo needs to be involved to define a policy, which arguably depends on the namespace it is published in
+14:07 <@Whissi> If we don't want to, then no.
+14:07 <+mgorny> Wiki can be changed anytime
+14:07 <@dilfridge> but provides versioned permalinks
+14:08 <@K_F> Whissi: well, a project page / site then, which allows for easy versioning
+14:08 <@K_F> or a git repo for that matter
+14:08 <@K_F> with tag for version
+14:08 <@ulm> but an Informational GLEP will be as stable as any other GLEP?
+14:08 <@K_F> ulm: well, it is, so any updates will require new glep etc
+14:09 <@ulm> yes, and it would still need council approval
+14:09 <@K_F> which is one of the reasons I'm not sure GLEP is the correct format
+14:09 <@K_F> yes
+14:09 <@Whissi> Anything with a stable URL will do it. But I see the question in future: Maybe mgorny or anyone else plans something which will build up upon a "Gentoo policy"... in this case we would require something more official like GLEP.
+14:09 <@dilfridge> right
+14:10 <@K_F> in the current state it isn't really a policy though, it is just one recommendation amongst other.. I don't necessarily see much value in council validating it vs it being published by a project of some sort
+14:10 <@dilfridge> if we want to re-use this as a dependency of something else ...
+14:10 <@K_F> if we were to mandate it, things would change of course
+14:11 <@Whissi> So reject for now and wait until we need a real policy?
+14:11 <@WilliamH> On a personal note, it is impossible as far as I know for me to follow standard gpg practices to sign someone else's key...
+14:11 <@K_F> in any case, that is my view on it .. so in the current form I'm going to vote to reject in any case
+14:12 <@WilliamH> I would definitely have to bend the rules sence I can't look at a government-issued id ;-)
+14:12 <@Whissi> WilliamH: You would really have to meet someone. I guess you won't show up alone... bringt someone with you, you trust... he/she will validate docs for you. Not?
+14:12 <@K_F> well, most government issued ID has RFID that you can scan, so in theory a reader could work , the fingerprint exchange would be more difficult, but an argument for QR code or like
+14:13 <@K_F> but yes, Whissi's proposal seems more useful in practice :)
+14:13 <@WilliamH> K_F: Hmm, true, I don't  own any kind of scanner though?
+14:13 <@K_F> WilliamH: you have apps for your phone for that kind of thing
+14:13 <@K_F> I have scanner that works on most passports (granted not all..)
+14:13 <@WilliamH> K_F: Probably, I don't know of an app but that doesn't mean there isn't one. :-)
+14:14 <@WilliamH> Whissi: Sure, but that can break down because I can't always depend on someone being right there to look at something for me.
+14:14 <@K_F> its on the sidelines of this discussion, but let me send over some name later
+14:14 <@Whissi> K_F: But how can you be sure that the RFID signal you read is authentic, i.e. from a real ID card?
+14:14 <@WilliamH> K_F: Sure. :-)
+14:14 <@K_F> Whissi: there is supposed to be some auth mechanism for it.. but again, lets discuss it outside of meeting
+14:15 <@Whissi> ACK
+14:15 <+Soap__> K_F: only a small number of global ID cards are RFID
+14:16 <@WilliamH> That's definitely a side discussion, so more details later are fine, it is just an interesting point.
+14:17 <@WilliamH> So do we want to vote on this or move on?
+14:17 <@ulm> I think that outright rejecting it would be to strong
+14:17 <@ulm> *too
+14:18 <@WilliamH> There still is the question of whether this needs to be a glep or whether it can just be done as an infra policy...
+14:18 <@K_F> "In its current form the proposed GLEP 80 has more merit outside of the GLEP structure" or something?
+14:18 <@dilfridge> the contents of the document make perfect sense
+14:18 <@ulm> we could send it back to the author, for revision, withdrawal, or whatever
+14:19 <@WilliamH> dilfridge: Sure, but the question is whether it fits the glep structure.
+14:19 <@dilfridge> yes
+14:19 <@ulm> IMHO it does
+14:19 <@leio> do we have an alternative structure for it? No, no-one is going to use some wiki link with question marks and ampersands in the URL
+14:20 <@K_F> leio: we could set up a git repo for policy and do a redirect from gentoo.org namespace of some versioned form
+14:20 <@K_F> gentoo.org/openpgp-signing-policy/v1
+14:20 <@K_F> kind of thing
+14:20 <@Whissi> In theory, git repo rely on used software. If Cgit will change... :D
+14:20 <@K_F> Whissi: then you change the 302
+14:20 <@WilliamH> Why not just https://www.gentoo.org/openpgp-signing-policy/ ?
+14:21 <@K_F> WilliamH: you want it versioned
+14:21 <@K_F> signatures today might not use same policy as signature in 2 years
+14:21 <@Whissi> https://www.gentoo.org/openpgp-signing-policy/v1/
+14:21 <@K_F> exactly
+14:21 <@dilfridge> alternatively we could say it just becomes a page on the main webserver (which is in git anyway)
+14:22 <@K_F> dilfridge: sure, but you'd have to handle versioning that can be more tricky with that
+14:22 <@K_F> a redirect where it points to a tag is rather easy
+14:22 <@K_F> point is, we shouldn't use a GLEP to provide a static URI
+14:23 <@WilliamH> gleps don't even have that kind of  versioning.
+14:23 <@K_F> that is a bad way to do it / requires additional tooling anyways
+14:23 <@K_F> WilliamH: no, you'd need new glep for new version of policy
+14:23 <@K_F> so glep-80, glep-110 etc
+14:23 <@K_F> instead of singing policy v1 , v2
+14:24 <@WilliamH> In that case we might as well do it as a glep...
+14:24 <@K_F> that doesn't have the same tracking of changes etc as a git repo would
+14:24 <@K_F> any signing policy really should live in an own repo
+14:24 <@WilliamH> I'm looking at something...
+14:26 <@WilliamH> Don't we have an informational glep type?
+14:26 <@K_F> we do
+14:27 <@K_F> but I'd rather see a GLEP that outlines where a signing policy lives and whom are responsible to update it (own project, superset with security and infra?)
+14:27 <@K_F> and the URI that is used for the long form.. than using it as the mechanism for the policy itself
+14:27 <@K_F> in particular since its not a policy, but a recommendation
+14:27 <@WilliamH> The glep is fine, but s/standards track/informational/
+14:27 <@K_F> (it is a signing policy, it is not a Gentoo policy)
+14:28 <@dilfridge> gentlemen,
+14:28 <@WilliamH> K_F: that's why it can't be standards track
+14:28 <@dilfridge> can we shove it somewhere now and discuss the finer points of formality over the next month?
+14:28 <@WilliamH> I'm fine with that dilfridge 
+14:28 <@K_F> dilfridge: wfm
+14:28 <@dilfridge> let's pick an url on the webserver, and that can still later become a redirect
+14:29 <@dilfridge> https://www.gentoo.org/openpgp-signing-policy/v1/  < OK?
+14:29 <@K_F> oh, by show, you don't mean the motion but the actual policy
+14:29 <@K_F> shove*
+14:29 <@K_F> I read it as deferring to next meeting and discussing in between
+14:30 <@WilliamH> K_F: same here, that's how I read it.
+14:30 <@K_F> but yes, that'd be my suggested URI
+14:30 <@Whissi> Can't we skip the URL discussion right now? If this will ever be required, a new GLEP will be required which can specify details like that.
+14:30 <@dilfridge> no, I meant, vote if the general text is OK, and then place it *somewhere* as v1, and think up a nice versioning scheme later?
+14:30 <@Whissi> Until then, we have stable GLEP URL. :)
+14:30  * WilliamH is with Whissi  on this, let's not bikeshed this thing to death.
+14:30 <@K_F> dilfridge: we can always do that, but my vote will be No until more things are sorted out
+14:30 <@K_F> its not ready in its current form
+14:31 <@dilfridge> we could write a glep on stable, versioned urls for policy documents
+14:31 <@WilliamH> Let's not dream up yet another url scheme unless we have to. ;-)
+14:32 <@K_F> its also to do with how third parties not familiar with GLEPs can use it
+14:32 <+mgorny> i don't see how using glep is wrong here
+14:32 <@WilliamH> Ar we deferring this for now?
+14:32 <+mgorny> i think the policy should be decided and updated by council
+14:32 <+mgorny> and have stable link
+14:32 <@K_F> and it misses some data normally found in signing policies like signature type
+14:32 <+mgorny> glep fulfills those requirements
+14:32 <+mgorny> if you want extra url, it can redirect to glep
+14:32 <@WilliamH> mgorny: The more I think about this I tend to agree, but s/standards track/informational/
+14:33 <@WilliamH> We have  a couple of other informational gleps as well.
+14:33 <+mgorny> but this all sounds like inventing extra complexity for something that can be solved within existing model
+14:33 <@K_F> reading that doc I don't see whether to use a 0x10 or 0x13 signature for instance
+14:33 <+mgorny> K_F: and that's on point but i guess i should ask why this comes up now and not in the last month when glep was on review
+14:34 <@K_F> or the implied difference between them, which is normally used
+14:34 <@leio> if I may ask, where were these "it being a GLEP doesn't make sense" concerns prior to the meeting?
+14:34 <@K_F> mgorny: last month I've been out of country 3-4 days of the week, I haven't really read it before now
+14:34 <@K_F> as it came up
+14:34 <@Whissi> If don't need to reject this now. But when this would become a requirement, I am with k_f and would reject that GLEP which will make the current policy GLEP 80 a requirement.
+14:34 <@leio> oh, I should read backlog, same question already happened.
+14:35 <@WilliamH> K_F: IF it is an "informational" glep, it is fine.
+14:35 <@Whissi> s/If/I/
+14:35 <@WilliamH> Sorry, Whissi  not k_f :p
+14:35 <@WilliamH> ^^
+14:35 <+mgorny> given all that was said, i think the best course of action will be to defer it to next meeting, and in the meantime let K_F and whoever else has any concerns voice them on ml
+14:35 <@K_F> WilliamH: I don't see it like that, the glep should rather define the structure for it and whom can update it (which I'm fine with being council), and by all means a proposal for a first version
+14:35 <@WilliamH> mgorny: wfm
+14:36 <@WilliamH> I'm fine with deferring to ml fo r now...
+14:36 <@WilliamH> moving on:
+14:37 <@WilliamH> 3. Update GLEP 63 to require encryption subkey:
+14:37 <@WilliamH> bug 681802
+14:37 <+willikins> WilliamH: https://bugs.gentoo.org/681802 "glep-0063: Require encryption subkey, and make primary certify-only"; Documentation, GLEP Changes; CONF; mgorny:glep
+14:37 <@dilfridge> ok so
+14:37 <@dilfridge> here I have a comment about the content
+14:38 <@dilfridge> "require encryption subkey" is definitely ok and good
+14:38 <@dilfridge> "make primary cert-only" is imho unnecessary, and since it relies on kinda hidden features, could make trouble
+14:38 <@dilfridge> so if we vote about this we should probably treat the two things separately
+14:39 <@Whissi> dilfridge: ISn't that just a recommendation, not a requirement?
+14:39 <+mgorny> dilfridge: it's a recommendation
+14:39 <@dilfridge> yes, but "recommending" to fiddle with the main key ...
+14:39 <@K_F> WilliamH: its stronger than that; "The developers should follow those practices unless there is a strong
+14:39 <@K_F>  technical reason not to (e.g. hardware limitations, necessity of replacing
+14:39 <@K_F>  their primary key)."
+14:39 <@K_F> ehrm, Whissi
+14:40 <+mgorny> yes, and having prior signatures with primary key is a valid reason not to
+14:40 <+mgorny> otoh it's a good recommendation for new keys
+14:40 <@Whissi> K_F: I don't read it like that. If I don't want to do that, I won't do it and you cannot take action against me for violation. That's my understand of "recommendation" vs" requirement. I don't know "strong recommendations"
+14:40 <+mgorny> and the gkeys guide agrees with it
+14:41 <@K_F> but it is a good recommendation , so I don't particularly have a problem with it being one
+14:41 <@K_F> the invalid prior signatures is my concern, and from security point of view it is really moot
+14:41 <@WilliamH> Since it is just a recommendation, we can't complain if someone doesn't either.
+14:41 <@K_F> but it can help a case where subkey expires to avoid a signature from primary
+14:42 <@K_F> which would be the strongest argument for it
+14:42 <@Whissi> Yes, I agree with the _recommendation_. dilfridge, would you like to elaborate your concerns?
+14:42 <@Whissi> Do you just fear to break your existing key?
+14:42 <@dilfridge> mostly that I want to avoid guiding people into a way that breaks their stuff
+14:42 <@dilfridge> I'm not going to touch my primary key because I dont remember anymore if I ever used it for signing
+14:42 <@Whissi> Heh, make backups before you do such a change ;-)
+14:43 <@WilliamH> dilfridge: Yeah I don't want to mess with my primary either.
+14:43 <@K_F> Whissi: well, if the change ended up severely breaking things, and it is published to keyserver that isn't necessarily sufficient
+14:43 <@K_F> but this change shouldn't really be fatal
+14:44 <@K_F> it was worse when needing to hack gpg to do it, now it is a built-in feature
+14:44 <@WilliamH> If it is just a _recommendation_, we can't say a word to people who don't make the change.
+14:44 <+mgorny> dilfridge: if you change it, you can change it back ;-)
+14:44 <@K_F> WilliamH: right
+14:44 <@dilfridge> ok sounds more harmless than I thought
+14:44 <+mgorny> that's the good thing about it
+14:45 <+mgorny> compare with how i broke releng key
+14:45 <+mgorny> then fixed it
+14:45 <@ulm> why is it needed though?
+14:45 <@K_F> ulm: the case I outlined above is my strongest argument
+14:45 <@ulm> i.e. what is the problem with the primary having S capability?
+14:45 <@K_F> 21:41 <@K_F> but it can help a case where subkey expires to avoid a signature
+14:45 <@K_F>              from primary
+14:45 <@K_F> by default gpg would sign using primary if signing subkey expires
+14:45 <@K_F> as long as it has S caps
+14:45 <@ulm> ok
+14:46 <@K_F> of course, if the key actually is offline, as it should
+14:46 <@K_F> you wouldn't end up in that scenario in any case
+14:46 <@K_F> as the key material isn't there, and it'd just fail
+14:46 <@K_F> so from that PoV it is useless anyways :)
+14:46 <+mgorny> i doubt most devs are going to ever adopt offline key
+14:47 <+mgorny> nitrokey/yubikey stuff is more likely
+14:47 <+mgorny> and i don't think it protects from primary key usage
+14:47 <@K_F> well, separate hardware token
+14:47 <@K_F> as the primary would need to be in signing slot you can't do it on one token
+14:47 <@K_F> so you'd need to insert the token for the primary, which is same difference wrt fallback fail
+14:48 <@K_F> tl;dr; I don't mind updating the recommendation, but it has very little effect on anything
+14:49 <@K_F> it does have a certain signalling effect, though
+14:49 <@WilliamH> Do we have a motion then, do we want to vote on one or two items?
+14:49 <@Whissi> OK, let's vote on this.
+14:50 <@WilliamH> Who wants to put forward a motion?
+14:50 <@Whissi> I don't need to split, I can vote on the complete GLEP update. Anyone else who want to split?
+14:51 <@K_F> voting on full update is fine for me
+14:51 <@WilliamH> Ok, vote on whether or not to update glep 63 to require encryption subkey and mrecommend that primary key be for certification only:
+14:51 <@WilliamH> recommend *
+14:52  * Whissi yes
+14:52  * dilfridge yes
+14:52  * K_F yes
+14:52  * leio yes
+14:52  * WilliamH abstain
+14:52  * ulm yes
+14:52 <@WilliamH> The motion carries
+14:52 <@WilliamH> moving on:
+14:53 -!- NP-Completeass is now known as NP-Hardass
+14:53 <@WilliamH> 4. discuss disbanding or better specialization of herd-like projects:
+14:53 <@WilliamH> https://archives.gentoo.org/gentoo-dev/message/5a6ae394023c56a4830b4e2e9472a6bd
+14:54 <@WilliamH> In my opinion, there's not really much we can do here.
+14:54 <@WilliamH> Projects can be created or disbanded at any time without council involvement.
+14:54 <+mgorny> the problem is, most projects don't reply to me
+14:54 <+mgorny> and if i started disbanding them because nobody cared to reply, you can imagine what the result would be
+14:55 <@Whissi> I want to throw in a comment: mgorny's example was cron herd and that it's ridiculous to be responsible for all cron implementation..  not a good example: The idea for cron herd was that we agree on things like system cronjobs... so you can switch between cron implementations.
+14:55 <+NeddySeagoon> So disband them ... you only need do one
+14:55 <@WilliamH> mgorny: on option is, if the developers in the projects are still active, assign the bugs to the devs directly.
+14:55 <@WilliamH> one *
+14:55 <+mgorny> Whissi: and that's why i proposed reducing the project to carry policy tasks without maintaining everything
+14:56 <@Whissi> OK.
+14:56 <@K_F> WilliamH: right, I think a two-tier approach might be beneficial here, recommeding (strongly) a primary developer responsible even for these projects
+14:56 <+mgorny> i mean, i gave multiple suggestions, and the project decided to disband itself
+14:56 <@K_F> that is what we do in crypto, for instance..
+14:56 <+mgorny> K_F: like, enforcing projects to actually elect a lead?
+14:57 <@K_F> mgorny: I was thinking per-package to begin with, but that would likely help in gauging activity
+14:57 <@WilliamH> Let's not go down that path... ;-)
+14:57 <@K_F> but not necessarily help on the lack of knowing whom is responsible
+14:57 <+mgorny> K_F: in some projects like python it really doesn't make sense to make individuals responsible for the gross of 'easy' packages
+14:57 <@K_F> but most packages should have a primary developer assigned before the project
+14:58 <@K_F> mgorny: well, if the project is doing what it is supposed to, sure
+14:58 <@leio> by some interpretations, any project that hasn't had a lead election in the last 12 months does not exist anymore
+14:59 <@WilliamH> leio: let's not go down the path arguing about leads ;-)
+14:59 <+mgorny> well, maybe making lead elections obligatory and actively pursuing projects that don't do them could be a thing
+14:59 <@K_F> then you would have a contact point for any issues at least
+15:00 <@leio> (so you can go and disband gnome, because I've been busy with doing actual work there instead of running a lead election)
+15:00 <@WilliamH> leio: If you are the only dev in the project you are the lead.
+15:00 <@WilliamH> leio: according to some interpretations I've heard.
+15:00 <@K_F> would say it goes further than that
+15:00 <@K_F> if there hasn't been a lead election, the former lead stands
+15:01 <@K_F> but we could require a lead
+15:01 <@leio> You are the lead if the wiki project page says so, and the recorded election date isn't older than a year.
+15:01 <@leio> (debatable on the latter)
+15:01 <@WilliamH> K_F: some interpretations allow multiple leads.
+15:01 <@K_F> WilliamH: sure, thats no problem , really
+15:02 <@K_F> if you have two contacts that is fine as well, it is when it starts being "all members are lead" it becomes ugly
+15:02 < veremitz> how about divorcing projects from maintainership?
+15:02 <+mgorny> i don't think the problem is as much how many leads are there or how they are selected
+15:02 <@ulm> veremitz: we had that, it was called "herds" ;)
+15:02 <+mgorny> but that someone actually updates that
+15:02 < veremitz> ulm: ugh.
+15:02 <@leio> they are divorced, except when they aren't, because someone decides to undertake a project that doesn't maintain any packages (desktop project comes to mind)
+15:03 <@WilliamH> K_F: there's no restriction -- all members can be leads.
+15:03 <@WilliamH> according to glep 39
+15:03 <@WilliamH> So we as the council really can't mess with it.
+15:03 < veremitz> ulm: I'ma write a GLEP .. projects cannot maintain packages .
+15:03 <@K_F> WilliamH: indeed
+15:04 <+Soap__> tbh, isnt this just a semantic debate to paper over the fact that we are just understaffed?
+15:04 <+mgorny> returning to the main topic
+15:04 < veremitz> A package may be 'associated' with a project, but cannot be maintained by it.
+15:04 <+mgorny> what i'd use is some blessing for my effort
+15:04 < veremitz> Soap__: elephant in room.
+15:04 <@dilfridge> ok
+15:04 <@dilfridge> so
+15:05 <@K_F> Soap__: not necessarily, in many projects it is actually individual maintainers following specific packages
+15:05 <@dilfridge> the point is, we have projects that do not care for all of their packages, right?
+15:05 <@K_F> so you simply don't know if it is maintained or not if one dissapears
+15:05 <@leio> yeah, like sound@ with Soap__ in it *grin*
+15:05 <+Soap__> dilfridge: literally every project
+15:05 <@K_F> for those kind of structures, they aren't really acting like a project
+15:05 <+Soap__> leio: h8er
+15:05 <+Soap__> I spent like a year polishing up libsndfile/adplug and audacious
+15:05 < veremitz> [re]define "project"...
+15:05 < veremitz> [re][re][re]define**
+15:06 <@dilfridge> we have some distinct problems here
+15:06 <@leio> Soap__: exactly; what about the other 100+ packages
+15:06 <@dilfridge> one is, as someone who has been around for a while, *I* know that I can do with most sound packages whatever I want
+15:06 <@WilliamH> One thing we could do is say that every package should have a person maintaining it and they should be listed above any project in metadata.
+15:06 <@dilfridge> others dont, which leads to unnecessary waiting times and annoyance
+15:07 <@leio> mark projects as maintainer-needed
+15:07 <@dilfridge> WilliamH: doesnt *always* make sense, see kde
+15:07 <@leio> (but who could do so is another matter)
+15:07 <@dilfridge> where there (at least was) is a team which takes care of the whole bundle
+15:08 <@dilfridge> ftr I think trying to re-organize unresponsive teams makes sense
+15:09 <+mgorny> or gnome, or xfce where all the things are released together, quite similar in maintenance and it just makes sense for N people to be able to handle them
+15:09 <@WilliamH> I think we should s/herd-like project/non-responsive project/ in this discussion.
+15:09 <@K_F> right, so it shouldn't be a requirement to always have a primary
+15:09 <+mgorny> non-responsive project is a separate problem
+15:09 <@K_F> but yes, I agree with dilfridge , it makes sense to act on specific teams where we're concerned about the overall project responsibilities (the project actually taking care of all the packages )
+15:09 <@dilfridge> as long as team members are actually sharing work and talking to each other stuff is fine
+15:09 <@K_F> yup
+15:09 <+mgorny> there are teams that make sense but are non-responsive
+15:10 <@dilfridge> !proj sound
+15:10 <+willikins> dilfridge: (sound@gentoo.org) aballier, chainsaw, chutzpah, radhermit, soap
+15:10 <+mgorny> and there are teams that don't make sense, are responsive but fail to fulfill their dut
+15:10 <@K_F> to try to wrap things up, I'm not sure if we're ready to vote on any policy, but we could create some form of statement
+15:10 <@dilfridge> hey there when did you have your last team meeting? :)
+15:11 <+mgorny> the biggest problem is when everybody sees that a project is dysfunctional, makes little sense but a single person being that project doesn't see it that way
+15:11 <+mgorny> desktop-misc is a perfect example of that
+15:12 <+mgorny> project that literally maintains 'miscellaneous' packages
+15:12 <@Whissi> dilfridge: How do you define a team? *duck*
+15:12 <@dilfridge> s/team/project/
+15:12 <@WilliamH> !proj desktop-misc
+15:12 <+willikins> WilliamH: (desktop-misc@gentoo.org) jer, johu
+15:12 <+NeddySeagoon> Are projects with packages the only problem ?  What of Wiki, infra, PR comrel ...
+15:12  * dilfridge wonders when jer and johu last talked to each other
+15:13 <+mgorny> NeddySeagoon: the discussion is about unmaintained-but-apparently-maintained packages
+15:13 <@K_F> NeddySeagoon: for the prupose of this discussion, I'd say it is related to cleaning up package maintenance
+15:13 <@dilfridge> wiki consists of maffblaster, he can talk to himself
+15:13 <@leio> he can't; his wife and co-workers might put him in an institution.
+15:14 <+mgorny> another example is voip
+15:14 <+mgorny> it was dysfunctional, disbanded, then recreated without glep39-required rfc ('because you don't need to listen to negative feedback')
+15:15 <+NeddySeagoon> My point is that its not a project issue, its an accurate package maintainer issue.  Every package can have a lead maintainer.  Groupings of maintainers will form natually
+15:15 <+mgorny> and aims to maintain a set of packages the current team lead happens to be interested in
+15:15 <@K_F> NeddySeagoon: the problem is when it hides pakages not actually being maintained
+15:15 <@dilfridge> ^that
+15:16 <@dilfridge> and when noone of the project responds to package bugs
+15:16 <+NeddySeagoon> K_F: Disband projects as maintainers.
+15:16 <@K_F> NeddySeagoon: no, that'd be a wrong move
+15:16 <@dilfridge> you file a stable request because of some needed dependency, and wait for a month until you time it out
+15:18 <+mgorny> i've treecleaned packages that were broken for years
+15:18 <@K_F> I'd rather require a project lead to be available, and able to answer to email etc for that package if others doesn't respond
+15:18 <+mgorny> and found some bugs that were fixed years ago but nobody closed them
+15:18 <@K_F> but for that matter, if email to the project alias goes unanswered, it is a treecleaning candidate
+15:18 <@leio> I maintain 400+ packages, different projects, different context switches; I'd go crazy if everything was lumped behind a "My Bugs" bugzilla report
+15:19 <@leio> (in fact, I almost never look at bugs assigned to me; they'll be lost unless I notice e-mail)
+15:19  * WilliamH is guilty of that at times
+15:19 <@WilliamH> I think all of us are.
+15:19 <@WilliamH> probably.
+15:20 <+mgorny> yes, and this is just makes things worse for treecleaners
+15:20 < veremitz> the reverse is also true however ..
+15:20 <+mgorny> there's a lot of valid open bugs
+15:20 <+mgorny> and you end up having to filter through a lot of them
+15:20 <+mgorny> then verify the remaining ones
+15:20 <@Whissi> k_f: But what do you do if lead isn't around? Not many people will ACK and resign so that somebody else can become lead... like they say "Yeah, but I'll have more time next month. Next month. Next month. Next month." Oh, half year later...
+15:21 <@K_F> Whissi: well, glep39 allows for re-election called by others
+15:21 <@K_F> and that isn't necessarily an issue if the lead can direct to the one actually "responsible" for said package
+15:21 <@K_F> or just ack a removal
+15:21 <+NeddySeagoon> That assumes that someone wants the job
+15:21 <@WilliamH> NeddySeagoon: heh
+15:22 <@Whissi> If you call for re-election you will create tension. And what do you do if current lead will be around in that time just to fight for his/her lead position but once the uprising is stopped, thing will be like before...
+15:22 < veremitz> ok for projects that 'make sense' .. how about you assign packages to the project lead (because that should be a thing) as a nominal maintainer ..
+15:22 <@K_F> it isn't necessarily the lead that needs to fix the package, just be available for queries
+15:22 <+mgorny> ok, for something more general
+15:22 < veremitz> but I think you need to divorce project from maintainer.
+15:23 <+mgorny> do you think treecleaners are suitable to disband projects?
+15:23 < veremitz> that is always going to be an issue for obscurity
+15:23 <+NeddySeagoon> mgorny: Yes
+15:23 <@WilliamH> mgorny: yes
+15:23 <+mgorny> or should there be some higher-order procedure when project doesn't reply
+15:23 <+mgorny> i mean, i've so far disbanded projects either because they agreed, or were empty
+15:23 <+NeddySeagoon> Thats fine.
+15:24 <@WilliamH> I tend to agree with NeddySeagoon 
+15:24 <+mgorny> now, if projects has members but they don't reply, i'm not sure what to do
+15:24 < veremitz> mgorny: raise to council?
+15:24 <@K_F> mgorny: for more complex cases it likely should go via council , but on a per-project basis
+15:24 <+NeddySeagoon> mgorny: HAve you tried to disband council?  :)
+15:24 <+mgorny> NeddySeagoon: saving that for open floor
+15:24 < veremitz> NeddySeagoon: LOL
+15:24 <@WilliamH> lol
+15:25 <@Whissi> Not sure which problem this will solve. If I know that I just need to reply... well, my reply won't help treecleaners much but now there's a reply, they cannot proceed. So the underlying problem is still there.
+15:25 <@K_F> mgorny: i.e a filed bug for disbandoning it, requesting feedback from any listed members and then a specific decision
+15:25 <@WilliamH> K_F: I'm not sure about that... mgorny: Are we talking about projects that have active members but are opposed to disbanding?
+15:25 < veremitz> Whissi: it can still be raised to council...
+15:26 <+mgorny> i've filed a number of bugs recently, and most of them received no reply so far
+15:26 <@leio> such bugs may have more success if the project members are CCed individually as well, together with a comment that send them e-mail for it
+15:26 <@K_F> I would also recommend emailing the project, as bugmail can easily get lost
+15:26 <@K_F> its easier to spot an email to the alias
+15:26 <@leio> many have per-project mail filters sending them to a separate folder that is never read
+15:26 < veremitz> step1) bug step2) email step3) idk .. step4) disband?
+15:26 <+mgorny> i think i'll try talking to people directly
+15:27 <@leio> (and then also the same happens for all bugzilla generated mail otoh...)
+15:27 <+mgorny> but then, i hoped for some council-backed opinion that herds are not cool
+15:28 <@leio> we can't exactly fight with metastructure glep; not cool, yes, but we can't override that glep to say they aren't allowed
+15:28 < veremitz> New GLEP! w00t!
+15:28 < veremitz> :p
+15:28 <@WilliamH> leio++
+15:28 <+mgorny> yeah, i suppose it'd be best to address specific projects once we establish which ones really pose a problem
+15:28 <@WilliamH> veremitz:  the issue is that any changes to glep 39 have to be approved by a full community vote.
+15:28 <@K_F> mgorny: that is my take
+15:29 < veremitz> WilliamH: uhoh its untouchable :(
+15:29 <+mgorny> can we at least get some formal call for projects to review the packages they're maintaining and drop those they ain't?
+15:29 <@WilliamH> veremitz: the council doesn't have the authority to change it.
+15:29 <@K_F> mgorny: I'd be fine with that
+15:29 < veremitz> WilliamH: how is that even possible?! thats stalemate in digital form...
+15:29 <@WilliamH> veremitz: it isn't untouchable, it just has a different procedure.
+15:29 < veremitz> uhm.
+15:29 < veremitz> its untouchable :)
+15:30 <+NeddySeagoon> A full dev base vote can be organised.  It happens for council every year.
+15:30 <+mgorny> veremitz: could you please stop making comments that don't add anything to the discussion? they're cluttering the logs for people who are interested in merits of the discussion
+15:30  * veremitz ignores mgorny again.
+15:31 <@WilliamH> Here's a draft:
+15:31 <@ulm> we used to have +m during meetings, why don't we any more?
+15:31 < veremitz> laziness :P lol
+15:31 <@K_F> ulm: we only do it if the SNR becomes too low
+15:32 <@K_F> I'd rather let chair +q someone than making +m standard again
+15:32 < veremitz> K_F: that rarely ever gets reset , fwiw
+15:32 <@K_F> not the end of the world..
+15:33  * veremitz noted anyhow .. *takes a break*
+15:33 <@Whissi> I would say: Next topic. We won't decide anything _today_ about this topic and discussion should happen on mailing list, at least not during meeting, right?
+15:33 <@leio> can we get back on track please, it's been 1.5h.
+15:33 <@WilliamH> Whissi: I'm fine with that...
+15:33 <@WilliamH> moving on:
+15:33 <@WilliamH> 5. Open Bugs with council envolvement.
+15:33 <@WilliamH> involvement *
+15:33 <@K_F> Whissi: I like mgorny's idea of statement to review list of packages for projects
+15:33 <@WilliamH> bug 677824
+15:33 <+willikins> WilliamH: https://bugs.gentoo.org/677824 "Deferred decision: Forums (specifically OTW)"; Gentoo Council, unspecified; CONF; k_f:council
+15:33 <@K_F> thats not a policy decision, but it could clean up a bit
+15:34 <@K_F> its been 1.5 hours already, lets defer it
+15:34 <+mgorny> K_F: maybe it should be just noted in meeting summary
+15:34 <@Whissi> I would close this bug as WON'T FIX.
+15:34 <@WilliamH> I'll note it in the summary as deffered.
+15:34 <@K_F> well, the decision was for a deferral, so that would require a vote
+15:34 <@WilliamH> differed. :p
+15:34 <@Whissi> Or at least I would like to vote on "Close as WON'T FIX"
+15:34 <@WilliamH> :p I can't type ;-)
+15:35 <@K_F> but my recommendation for it is discussion during a meeting that has light agenda
+15:36 <@K_F> and someone takes up some discussions again ahead of
+15:36 <@ulm> let's defer it for another month then
+15:36 <@WilliamH> ok
+15:36 <@WilliamH> bug 662982
+15:36 <+willikins> WilliamH: 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
+15:37 <@ulm> we have decided on that quite some time ago, but not much has happened
+15:37 <@ulm> the handbook still has /usr/portage all over the place
+15:37 <@ulm> repo snapshots are named portage-YYYYMMDD and have a top-level dir named "portage"
+15:37 <@WilliamH> Are we still waiting for zmedico also?
+15:38 <@Whissi> Can we update handbook before software is ready?
+15:38 <@K_F> Whissi: I'd say no
+15:38 <@ulm> WilliamH: not sure if portage defaults have been updated
+15:38 <@Whissi> I guess not, right
+15:38 <@WilliamH> Whissi: not really, it is a chicken-and-egg situation.
+15:38 <@ulm> the point is, someone should coordinate that
+15:39 <@ulm> preferably someone from releng, infra, or portage teams
+15:39 <@leio> I'm not sure of now, but my 13th March openrc test install ended up with /usr/portage
+15:40 <@ulm> maybe we should just revert our decision then :/
+15:40 <@WilliamH> Yeah, everything is still /usr/portage; there has been no movement... why?
+15:40 <@ulm> if everyone ignores it
+15:40 <@WilliamH> ulm: I'd rather see it go forward.
+15:41 <@WilliamH> ulm: we need to find out why it hasn't.
+15:41 <@Whissi> I'll try to coordinate between portage, releng and infra and give update next meeting.
+15:42 <@ulm> Whissi++
+15:42 <@K_F> Whissi++
+15:42 <@WilliamH> Whissi++
+15:42 <@dilfridge> excellent
+15:43 <+mgorny> I think my big infra projects are all done now, so I'll try to look into this
+15:43 <@WilliamH> We've already covered the next two, but I'll hilight them here for the log.
+15:43 <@WilliamH> bug 681802
+15:43 <+willikins> WilliamH: https://bugs.gentoo.org/681802 "GLEP 63: Require encryption subkey, and make primary certify-only"; Documentation, GLEP Changes; CONF; mgorny:glep
+15:43 <@WilliamH> bug 682294
+15:43 <+willikins> WilliamH: https://bugs.gentoo.org/682294 "GLEP 80: Identity verification via OpenPGP WoT"; Documentation, New GLEP submissions; CONF; mgorny:glep
+15:43 <@WilliamH> next bug:
+15:44 <@WilliamH> bug 676248
+15:44 <+willikins> WilliamH: https://bugs.gentoo.org/676248 "non-free licenses are accepted without user prompt"; Gentoo Linux, Profiles; CONF; whissi:licenses
+15:44 <@WilliamH> What are we waiting for on this one?
+15:44 <@K_F> iirc portage has been updated to allow for that to be toggled at some point
+15:44 <@K_F> not sure if the version is in stable yet
+15:44 <@WilliamH> Yes, it is in the latest stable release...
+15:44 <@ulm> that's in portage-2.3.62 which went stable on the last arch some days ago
+15:45 <@ulm> so we could flip the switch
+15:45 <@Whissi> OK. So last ping to releng and if they don't NACK we can flip?
+15:45 <@ulm> news item, I guess?
+15:45 <@Whissi> (don't want to break stages)
+15:45 <@K_F> needs a news item, yes
+15:45 <@ulm> and yes, we should talk to releng too
+15:45 <@K_F> but I'm fine with flipping
+15:46 <@ulm> I can draft a news item
+15:46 <@K_F> ulm++
+15:46 <@Whissi> News item for portage new feature? Why do think this is required? I would publish a news somewhere else but forcing everyone to read... it's not actionable, is it?
+15:47 <@Whissi> s/portage new/portage news/
+15:47 <@ulm> Whissi: it's a profile change
+15:47 <@K_F> iirc we gave releng some leeway, so coordination there might not be necessary
+15:47 <@K_F> and afaik no package has issue longer since the gentoo-sources was fixed
+15:47 <@ulm> hm, I see that releng isn't in CC of #676248
+15:48 <@K_F> Whissi: it'd alert them why they potentially get more license conflicts for current word
+15:48 <@K_F> so it is actionable if they want a broader permitted list
+15:48 <@K_F> it'd be a heads up how to deal with it and why it happens
+15:49 <@Whissi> I just want to avoid another news item which will show up when you do a fresh install... for existing users, ok... profile change... but for new installs.. mhhh
+15:50 <@ulm> release@g.o is releng on bugzie?
+15:50 <+mgorny> Yes
+15:51 <@WilliamH> Whissi: the only way to do that would be to make 19.0 profiles and deprecate all others.
+15:51 <@WilliamH> Whissi: which would also require us pushing amd64/ppc* through the 17.1 migration.
+15:51 <@WilliamH> Whissi: I think.
+15:52 <+mgorny> WilliamH: i don't think that'd make much sense
+15:52 <@K_F> well, it is easy for a user to control, and fix after migration
+15:52 <+mgorny> you'd push people through profile migration to change defaults... and possibly require them to alter configuration back
+15:52 <@K_F> so it doesn't require a separate profile imho
+15:52 <+mgorny> i.e. two actions instead of one
+15:53 <@WilliamH> mgorny: Yeah I tend to agree, I was just responding to how to make this newsitem not show up for new installs.
+15:53 <@dilfridge> please no separate profile
+15:53 <@dilfridge> that brings only more pain
+15:53 <@Whissi> I am only interested in reducing the list of outdated news items you will get when you do a fresh installation. That
+15:53 <@K_F> even new users might find it interesting, so I don't see it as a big issue
+15:53 <@Whissi> That's why I asked
+15:53 <@K_F> we likely want a N+X deprecation so it only shows up for a while, but..
+15:54 <@WilliamH> Ok, should we move on to the next bug?
+15:55 <@K_F> wfm
+15:55 <@Whissi> Well, you will get news items from 2006 today when you install Gentoo.... they ask you to do things not possible anymore. I want to avoid that the license change will show up for next 10 years. But yeah, maybe I should raise a sep. issue for 'outdated news items', next.
+15:55 <@dilfridge> hmm? what? yes...
+15:56 <@K_F> Whissi: right, we should clean up that, but we can do that with adding versions to the news items
+15:56 <@WilliamH> bug 642072
+15:56 <@dilfridge> or a Timeout: header
+15:56 <+willikins> WilliamH: https://bugs.gentoo.org/642072 "[Tracker] Copyright policy"; Gentoo Council, unspecified; IN_P; mgorny:council
+15:56 <@WilliamH> when can we close this?
+15:56 <@leio> the oldest news is 2013, not 2016 :P
+15:56 <@ulm> it's a tracker
+15:57 <@ulm> no council action for now, but I'd keep it open (maybe reassign?)
+15:57 <@WilliamH> moving on:
+15:57 <@WilliamH> bug 679250
+15:57 <+mgorny> yeah, tracker should be open until all bugs are resolved
+15:57 <+willikins> WilliamH: https://bugs.gentoo.org/679250 "GLEP 79: Gentoo OpenPGP Authority Keys"; Documentation, New GLEP submissions; IN_P; mgorny:glep
+15:57 <+mgorny> this has been implemented, so i'd like to mark it Final
+15:58 <@WilliamH> I suppose we can close it then?
+15:58 <+mgorny> i mean, i'd like a vote on making it final
+15:58 <@K_F> that likely requires a vote to make final
+15:58 <@dilfridge> so let's vote?
+15:58 <+mgorny> yes, either please vote or defer to voting on bug if you want to test it first
+15:58 <@dilfridge> we don't need to debate everything for 40min
+15:58 <@leio> it wasn't on agenda, I'm not prepared to vote, but that may not matter
+15:58 <@K_F> from a formality point, it was only requested on friday, so not really part of today's meeting
+15:59 <@K_F> but it is a formality in this case, so I'm ready to vote myself
+15:59 <@Whissi> I haven't tested as well
+15:59 <@WilliamH> leio: we are working on the open bugs.
+15:59 <@K_F> WilliamH: yes, but it was only made part of open bugs on friday
+15:59 <@K_F> so it is really next meeting's business
+15:59 <@K_F> or likely better, lets solve it in bug vote
+16:00 <@WilliamH> ok I'll drop it from the meeting then.
+16:00 <@K_F> either is fine with me
+16:00 <@leio> I'm fine with voting on the bug within 2 weeks
+16:00 <@WilliamH> bug 637328
+16:00 <+willikins> WilliamH: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; IN_P; mgorny:security
+16:00 <@K_F> yeah.. nothing has happened there.. good thing may has many holidays
+16:00 <@WilliamH> no updates I guess?
+16:00 <@WilliamH> heh
+16:00 <@WilliamH> moving on:
+16:01 <@WilliamH> 6. Open Floor:
+16:01  * WilliamH listens
+16:01 <@Whissi> NP-Hardass: Didn't you want to say something?
+16:01 <+NeddySeagoon> If coucil want to amend GLEP 39, elections can arrange the vote.
+16:01 < veremitz> *floor groans*
+16:01 <+NP-Hardass> Yeah, I'd like to meet privately with the council after open floor to discuss my commit privileges
+16:02 <@dilfridge> wfm
+16:02 <@WilliamH> We would need to propose changes on the project ml, and it doesn't have to be council doing the proposing.
+16:02 <+mgorny> well, i just wanted to say i'm dissatisfied that Council members once again comment on GLEPs during the meeting rather than during GLEP review
+16:02 <@Whissi> Sure we can talk privately but any decision must be public.
+16:03 <+NP-Hardass> And I'd like to add one more comment regarding the thread on the ML about things being more difficult for devs than users to state that in Sven's retirement notice, he said if he could contribute in the future, it'd be easier as a user (sort of reinforcing the point)
+16:03 <+mgorny> i get you don't have time but if you don't have time, you shouldn't have volunteered to be on the Council
+16:03 <+NeddySeagoon> WilliamH: There is a process for ratifying changes te GLEP39. Its nothing to be afraid of
+16:04 <@WilliamH> NeddySeagoon: Sure, but the council doesn't itself have to vote on changes the last I heard.
+16:04 <+NeddySeagoon> WilliamH: Correct
+16:04 <@WilliamH> NeddySeagoon: I'm just saying that anyone can propose changes to glep 39 and trigger a vote.
+16:04 < veremitz> WilliamH: someone has to set the ball rolling .. ;)
+16:05 <+NeddySeagoon> WilliamH: yes
+16:05 <@WilliamH> Anything else for open floor?
+16:05 < veremitz> WilliamH: mgorny's point?
+16:05 <@WilliamH> Which point?
+16:05 <+mgorny> i just made a statement, i don't expect people to reply to it
+16:06 < veremitz> fair enough
+16:06  * WilliamH bangs the gavel 
+16:06 <@WilliamH> Meeting closed.
diff --git a/meeting-logs/20190414.txt.asc b/meeting-logs/20190414.txt.asc
new file mode 100644
index 0000000..04434dc
--- /dev/null
+++ b/meeting-logs/20190414.txt.asc
@@ -0,0 +1,16 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAABCAAdFiEEnB9e/J8YI6T0NBsJm0Co7cr65zMFAly8rnMACgkQm0Co7cr6
+5zOQpBAAqj1Ron7oO464BKqBbvEsvY0yn7mO9iYXOgZCeTDcwGgtE3zsW0ztj4c9
+WH2vB9TAf1Al55IU9iv2qVgdq7WjfQ37IDucLqfHypbr+dQkF2QFeXFJCJTuwDvU
+nb+KqQfEiEPkQjjg14Sb39MhYErQSr+l9Lcwt3fXKNKWTkenYlcpcGKdyQ3LKNqn
+RabnF7bfBP3p4x3k0x06+lahMKnU2LRukJcQAV+QLwlYVYINIQlgnGUtZbeAlNXy
+0Go/dKANWG+pp9SHNlBJdewUEaalkJJ6dN6HWfEufrIFcxQv3YVfvYfYCIeyGjfh
+GLXr4viHMXFfCfd9oS6880MmS5vZnnrCI/gooMKNAJwhj6QCLnuCGzYpWMR8kqsh
+en3QbOLWHtQmte1M6wyMyYrR1e8vVoNvN3V495HUwlAfkoWLXI/ssmk1sHcNu68v
+13BPWau8Oum+IY06dbY0nnU4EixeNunBGLnKIyAM9FWSZkID50k6bXr7++6UGnC0
+946RPA4p28vJz41PCtNObD72K4F5LxnhlCimFUoNOS/TFZ7rtBnnEWlVANyw8OJu
+6f3iPYWIrEgfzhFM6piCWqnkMEUhpxGLUXsQ36HDUUAP2VZgx1caj0fEatyJl99O
+Pi8JXwkuLTT6+VCn6nQSLYKk3jOtcl5hvrlvTJK0F5VFT5Le5vs=
+=C1K8
+-----END PGP SIGNATURE-----