path: root/meeting-logs/20190414.txt

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.