path: root/meeting-logs/20180729.txt

<ulm> !proj council                                                     [20:00]
<willikins> (council@gentoo.org) dilfridge, k_f, leio, slyfox, ulm, whissi,
            williamh
* K_F here
<ulm> let's start
* Whissi here
<ulm> roll call :)
* slyfox here
<leio> here
<Whissi> darth_dilfridge or dilfridge|mobile: *ping*                    [20:01]
<Whissi> WilliamH: *ping*
<ulm> we have a quorum, but let's wait for a couple of minutes          [20:02]
<leio> two electricity glitches, might end up with desktop reboots randomly,
       but will be back quick in that case
<ulm> everyone ok with me chairing?
<slyfox> yup
* Whissi is fine with ulm chairing
<K_F> ulm: thanks for doing it :)
<ulm> would be good if everybody was present when we decide on the time
                                                                        [20:03]
<ulm> Constitute the new council                                        [20:05]
<ulm> the previous council had its meetings on the second sunday of the month
      at 18:00 UTC                                                      [20:06]
<ulm> would this be ok, or any suggestions for another time?
<K_F> personally I preferred the 19:00 UTC we had before, but sunday generally
      works best
<slyfox> i'm ok with 18:00 or 19:00
<Whissi> I'd appreciate 19:00 UTC during summer time in Europe.         [20:07]
<ulm> K_F: 19:00 wfm too, but if we change it, we should wait for confirmation
      from dilfridge and WilliamH
<K_F> well.. we've had that for several seasons ahead.. so should work :)
                                                                        [20:08]
<leio> I'm ok with anything from 16:00 to 19:00 UTC as start time on Sunday's
<ulm> ok, let's make it sunday 19:00 UTC then, pending ack from the absent
      members
<K_F> wfm
<ulm> next                                                              [20:09]
<ulm> Vote for continuing last council's workflow considering sending call for
      agenda items (2 weeks in advance), sending the agenda (1 week in
      advance) and have the meeting focussed, i.e., have major discussions on
      -project ML prior to the meeting
<ulm> everybody ok with that?
<K_F> yes.. I like the workflow
<leio> was there some sort of convention to /me votes?
<K_F> yes.. votes should be separate channel                            [20:10]
<ulm> leio: yes
<Whissi> Yes. But can we make sure that anything we should vote on must be
         present x days in its final state before meeting?
<K_F> the above really says it needs to be 1 week in advance
<K_F> but yes.. I agree we have been too lenient with a few points on that
<ulm> yeah, we should only vote on items on the agenda, and it should be sent
      in advance                                                        [20:11]
<slyfox> i'm ok with the existing workflow
<ulm> quick vote on the above?
* ulm yes
* slyfox yes
* leio yes
* K_F yes                                                               [20:12]
<Whissi> (I am more concerned about having everyone on the same page, that's
         why I asked for for "but make sure...")
* Whissi yes
<ulm> 5 yes 0 no, motion passed
<ulm> Appoint chairmen for this term's meetings
<ulm> we used to do 2 in a row if possible                              [20:13]
<ulm> and yes, 12 isn't divisible by 2 :)
<ulm> *by 7
<slyfox> :)
<ulm> so, I could do August
<slyfox> i can do september/october                                     [20:14]
<leio> I can do November/December
<ulm> I'd suggest to fill it up to december only, and do the rest when the
      absent members are there
<Whissi> OK.                                                            [20:15]
<K_F> sure.. let OBOBjan7feb for me then
<slyfox> sounds ok
<K_F> ehrmm... that was that latency I was talking about
<K_F> but that also works for me
<ulm> I've noted until December, and let's do the rest by e-mail
<ulm> we're not in a hurry there                                        [20:16]
<ulm> anything else for this item?
<ulm> seems not                                                         [20:17]
<ulm> next, GLEPs
<ulm>
      https://archives.gentoo.org/gentoo-project/message/85a3eac64894ef534e6824c2b2cea93b
<ulm> mgorny: you have the floor
<ulm> GLEP 63 update first
<mgorny> ok, so the latest version has had no negative feedback except for ...
         kumba? (sorry if i recall wrong) who only didn't read it all
                                                                        [20:18]
<mgorny> i think it's the best compromise i've been able to come up with after
         all the reiterations
<Whissi> I am sorry for not providing my feedback yet... but I have negative
         feedback:
<slyfox> i'd like to see explicit approval from security@
<Whissi> "2. Signing subkey that is different from the primary key, and does
         not have any other capabilities enabled."                      [20:19]
<Whissi> => I cannot approve this: There is no *technical* reason to ban keys
         where S and A capability is combined.
<mgorny> slyfox: i'd like to have seen that request 3 weeks ago
<K_F> Whissi: well.. for ssh there likely isn't but it is bad practice and can
      be tricked into signing server provided data
<Whissi> best practice != requirement.
<K_F> so its not bad for revealing private key data.. but it is bad practice
      in broader scope of things                                        [20:20]
<Whissi> Gentoo uses GPG only for commits. No need to enforce S and A split.
<mgorny> Whissi: is there a reason to have S+A keys?
<K_F> it is if a dev is tricked into signing random blob by signing onto
      service y
<K_F> that is reused for commit
<Whissi> ...                                                            [20:21]
<K_F> likelyhood is small.. but it is bad idea so best practice should be to
      avoid it
<K_F> removing dsa is likely less technical reason for though
<Whissi> mgorny: My argument is, that there is no _requirement_ to enforce
         such a limitation.
<mgorny> Whissi: there is no requirement ever to enforce any limitation
                                                                        [20:22]
<ulm> IIRC the current wording is already a compromise, it previously said
      there should be a dedicated gentoo signing subkey
<Whissi> I fully agree that best practice is different sub keys... but for a
         policy, I think we need technical reasons if we enforce something.
<mgorny> doesn't mean we should be allowing everything
<mgorny> the general idea is that we want people to have separate S+A keys as
         two layers of security
<K_F> the technical reason is signature re-use if service provides signing
      text                                                              [20:23]
<mgorny> i.e. that you need to *both* authenticate via SSH and sign your
         commits
<K_F> A capability is not limited to SSH and can be used for other services
      and protocols
<K_F> of which we don't know implementation details
<mgorny> if you use the same subkey for both, the gain is lost when the subkey
         is compromised
<K_F> so user logging into site using it can be asked to signed random blob
<ulm> Whissi: is there any technical reason why anyone couldn't have separate
      keys with S and A caps?
<K_F> which can be used to compromise gentoo
<ulm> smartcards allow for it
<darth_dilfridge> here                                                  [20:24]
<darth_dilfridge> sorry
<slyfox> just in time
*** darth_dilfridge (~quassel@gentoo/developer/dilfridge) is now known as
    dilfridge
<ulm> dilfridge: read the backlog please, we decided to shift to 19:00 UTC
<dilfridge> wfm
<ulm> good
<dilfridge> separate S and A keys are better                            [20:25]
<dilfridge> so I'd at least strongly recommend it
<Whissi> ulm: I am not aware of a specific reason why you would *need* S and A
         in one sub key... but my point is, that there's no reason to
         *enforce* a split and say "Nah, sorry... your key cannot be used with
         Gentoo because you combined S and A"                           [20:26]
* WilliamH is here late
<K_F> there is ..
<K_F> the security considerations mentioned above
<ulm> so, are we ready to vote on it now? or back to the MLs and reconsider in
      the August meeting?
<ulm> (which will be in 14 days)
<K_F> I'm ready to vote
<dilfridge> do we enforce separate S and C `
<mgorny> i should point out that current GLEP is already insufficient and is
         blocking infra from enforcing extended security
<dilfridge> ?
<leio> I haven't seen a compelling reason to remove the strict requirement,
       despite it maybe not having a technical reason to be required (to not
       have S+A)                                                        [20:27]
<ulm> Whissi: the GLEP was discussed at length
<K_F> dilfridge: yes
<Whissi> No. Given that you cannot split down... if user can be tricked to
         signed on auth, user can be tricked to sign as well.
<leio> my only concern is if 2 years + grace is sufficient for those people
       with primary keys in safe vaults
<Whissi> -ed
<leio> but seems like it is
<Whissi> leio: #4 is also on my list
<slyfox> as a general note i find docs lacking exact commands to execute to
         get a valid setup. i wonder if it's just me :)                 [20:28]
<K_F> its basics.. you really should know it as a dev
<WilliamH> I also find documentation lacking for gpg, but I don't know if that
           belongs in the glep.
<mgorny> can't really update docs when you can't agree on a spec
<K_F> but plenty of docs around.. start with gnupg manual and GPH
<mgorny> unless you want to write docs against the spec, or docs based on
         draft spec, or docs that are just plain wrong                  [20:29]
<ulm> mgorny:
      https://gitweb.gentoo.org/data/glep.git/commit/?h=glep63-updates&id=ea9b2428308bd428904a979d507245dd1d8c4d0f
      is the current version?
<Whissi> Regarding "4. Expiration date on key and all subkeys set to no more
         than 900 days into the future." => There's no technical reason to ban
         primary key which is valid for >=3y.                           [20:30]
<K_F> as a general note, I dont like the trend lately where rewuiring certain
      common sense id out window and people rewuiesting policied for basic
      things, and the reduced requirementd of developers
<Whissi> Setting an expiration date is best practice. But it is best practice
         for the life in web of trust which doesn't apply for Gentoo:
<Whissi> In the web of trust I'll meet someone somewhere. Maybe just ONCE in
         my lifetime. Then it make sense to use the expiration date as
         something like a "dead man switch", i.e. if this person cannot proof
         access to key material every x years by updating expiration date, I
         know that this trust channel is dead and that I need to establish a
         new one.
<Whissi> However, in Gentoo, someone with SSH access can add/remove keys all
         the time. We don't use expiration time and have no need for something
         like a "dead man switch" because we have undertakers which will
         ensure that non-active maintainers will be removed in time.
                                                                        [20:31]
<mgorny> ulm: lacking one commit, just pushed the update
<Whissi> s/maintainers/devs/
* WilliamH would rather not have a forced expiration on the primary key
<mgorny> Whissi: the keys are used not only for gentoo                  [20:32]
<mgorny> we assume people are using the same key for mails etc.
<dilfridge> do we really have to have this debate "how much can we water down
            things semi-safely?"
<ulm> ok, unless we send it back to the mailing list, we won't be able to
      update the glep during the meeting
<K_F> and wr likely want to use wot in futurr for new dev introductions etc
<dilfridge> It's kinda silly not to require something stricter than actually
            precisely needed
<mgorny> people are using those practices outside gentoo, and that's why they
         should be good
<ulm> motion: accept the GLEP 63 updates in
      https://gitweb.gentoo.org/data/glep.git/commit/?h=glep63-updates&id=bf99712e1e5e9b68a70be1aa93669e2f7192501b
                                                                        [20:33]
<dilfridge> K_F: you need a better mobile irc client :P
<ulm> please vote
* ulm yes
* K_F yes                                                               [20:34]
<leio> do those commits match what was sent to gentoo-dev as [PATCH v5 ...] +
       v5-amendment wrt uid?
<ulm> vote no if you think that it should go back to lists
<Whissi> mgorny: Exactly, and because of 900d I'll get problems because my key
         is used somewhere else where it won't be automatically updated.
         Enforcing <3y for no reasons will add pain for no reason.
<ulm> leio: they should
* slyfox yes
<Whissi> Ermm, I am not just finished?!
<Whissi> And you are starting a vote?
* dilfridge yes
<Whissi> Thanks for nothing.
* Whissi NO
<ulm> leio: i.e. rendered version in
      https://dev.gentoo.org/~mgorny/tmp/glep-0063.html
<ulm> Whissi: by the workflow we just approved, the meeting should be focused
                                                                        [20:35]
<K_F> discussion really should be on ml to begin with
<ulm> major discussions on -project ML prior to the meeting
* leio yes
<mgorny> leio: yes, i've sent git patches from that repo
<ulm> WilliamH?                                                         [20:36]
* WilliamH no
<ulm> that's 5 yes and 2 no
<ulm> motion passed                                                     [20:37]
<WilliamH> I don't mind expiration on my subkeys, but I would rather not put
           one on my primary key
<ulm> guys, this point was discussed at length for several weeks        [20:38]
<dilfridge> next agenda item
<leio> You can extend the date of that primary key at any time, for example
       when you extend it for the subkeys for which you don't mind it.
<ulm> dilfridge: yes
<slyfox> maybe worth having F.A.Q. explaiing rationale and ways out of common
         problems                                                       [20:39]
<ulm> GLEP 77 "general resolution"
<ulm> that one has an official draft at
      https://www.gentoo.org/glep/glep-0077.html
<WilliamH> Can you put one on a primary that didn't have one before?
* WilliamH doesn't want to make a third key
<mgorny> WilliamH: yes, just like on subkey
<K_F> given the short terms of council to begin with I dont wee much reason
      for this
<mgorny> WilliamH: but plz, after the meetig
<mgorny> glep77; here it seems that the community at large didn't have any
         specific requests                                              [20:40]
<K_F> (and yes, I miss my blackberry for typing)
* Whissi votes YES on GLEP 77
<mgorny> there were a few concerns about large numbers but without any
         suggestions on what to change
<ulm> mgorny: the question is if we need such a thing                   [20:41]
<mgorny> yes, that's one of the questions
<leio> I'd be interested in a way to gauge the opinion of other developers in
       a better way than perhaps just a vocal minority lobbying and others not
       caring; this doesn't provide it, but could be worked on separately once
       needed, especially when the voting systems get extended to support more
       than a ranking schulze
<ulm> but well, it won't get in the way of any normal workflow, I think
<mgorny> i think it's a good thing to have in general as it puts a formal way
         for electorate to enforce their wishes                         [20:42]
<dilfridge> leio: the developer opinion is a "bimodal distribution", i.e.
            different, disjunct groups... otherwise it couldnt be that both
            Whissi and me have a seat
<leio> The existing way to enforce those wishes is to participate in the next
       elections accordingly. This is how this usually works
<mgorny> let me put it like this
<mgorny> right now, if some people disagree with Council, they express their
         opinion on mailing lists                                       [20:43]
<dilfridge> The reason why I support GLEP77 is because I'm sick of noisy
            people claiming they speak for the majority without any proof of
            that
<mgorny> they have no formal way of doing it, so they have to stay with anger
         and 'demonstrations' and how'd you call it
<mgorny> even if they don't have any real support, they create negativity
<mgorny> (and we don't have any way of gauging whether they do represent
         majority or not)                                               [20:44]
<K_F> that will happen one way or other anyways
<K_F> its not going to be solved by rhis glep
<dilfridge> so give them a way to prove they have support of the majority, and
            shut up otherwise :P
<mgorny> procedure like GLEP 77 means we say 'if you believe so, please use
         general resolution'
<mgorny> so they either do it, and win, or they get proven 'community
         disagrees with you'
<leio> I don't mind something like it, if appropriate safeguards are in place
       that don't end up with those carding to void a decision vote, others
       obviously don't worry about it and end up not voting, and then of
       course the void choice wins; I'm not sure 2:1 of who voted is enough to
       prevent such a situation, but it's something.
<K_F> they get their say in next vote that is <12 months away           [20:45]
<dilfridge> K_F: last term was painful enough, 12 months can be very long
*** rich0 (~quassel@gentoo/developer/rich0) has quit: Quit: rich0
<K_F> its really not
<mgorny> K_F: bad Council can do a lot of harm in 12 months
<ulm> so, looks like the council's opionion is split? should we just vote?
                                                                        [20:46]
<ulm> *opinion
<mgorny> not saying it's something that will happen
<mgorny> but i believe we owe people that
* Whissi wants to vote
<K_F> yeah dont think there is more to discuss as such
* K_F no
<dilfridge> I'm less worried about the "bad council" case since people did get
            elected
<slyfox> +1 for voting
<dilfridge> let's vote
<ulm> motion: accept GLEP 77
* K_F no
* slyfox yes
* dilfridge yes                                                         [20:47]
* Whissi yes
* ulm abstains
<slyfox> leio, WilliamH ^
<mgorny> leio: the glep had example numbers in it, sec                  [20:48]
<mgorny> leio: 2:1 means at least ~50 devs voting yes
<leio> yes, I looked at those; I'm just not sure percentages from who votes vs
       percentage from electorate count is ok
<leio> though ultimately it means people need to be lobbied to care, then.
                                                                        [20:49]
<mgorny> leio: that's why we combine both
* leio yes
<ulm> WilliamH?
* WilliamH yes
<ulm> motion passed with 5 yes votes, 1 no vote, one abstention         [20:50]
<ulm> anything else for this item
<ulm> ?
<WilliamH> One concern I have: some reactionary devs not liking an upstream
           change and using this to force our devs to carry patches to do
           something a "Gentoo" way that is not supported upstream.
<mgorny> do we assume that's enough or do we need a full dev vote to confirm?
<ulm> we'll do GLEPs 1 and 14 with the open bugs
<dilfridge> mgorny: I doubt that's needed since we only restrict powers of the
            council                                                     [20:51]
<mgorny> dilfridge: i agree
<dilfridge> s/restrict/delegate/
<mgorny> if people disagree, they can use GR to void approving GR ;-)
<ulm> mgorny: no full dev vote, I would say
<ulm> but we can vote on that too :)                                    [20:52]
<ulm> motion: have a full dev vote for approval of GLEP 77
* ulm no
* dilfridge no
* Whissi no
* slyfox no                                                             [20:53]
* K_F no
<ulm> leio: WilliamH: ^^
<leio> I haven't thought of these bureaucratic nuances, so
* leio abstain
<ulm> anyway, 5 no votes so the motion cannot pass                      [20:54]
* WilliamH no
<ulm> 6 no votes, 1 abstention
<ulm> let's move on
<ulm> Default locations for repositories, distfiles, and binpkgs
<ulm>
      https://archives.gentoo.org/gentoo-project/message/080ac812b76851f53230d88a66c0fd3b
<dilfridge> whee
<ulm> last message in dev was
      https://archives.gentoo.org/gentoo-dev/message/256c720b5e16b00304645cbacfc52413
<ulm> i.e.:                                                             [20:55]
<ulm> /var/db/repos/gentoo
<ulm> /var/cache/distfiles
<ulm> /var/cache/binpkgs
<ulm> anyone wants to discuss it further here, or should we just vote on this
      one?                                                              [20:56]
<Whissi> Can somebody explain why FHS uses singular (/var/log) and we use
         plural (repos, distfiles)?
<mgorny> Whissi: hysterical raisins
<WilliamH> Whissi: huh?
<dilfridge> vote, we've had enough bikeshed
<mgorny> i.e. it doesn't really matter, and there's no point in changing paths
         already in use for pl vs s
<ulm> Whissi: FHS uses plural too
<ulm> e.g. /media                                                       [20:57]
<Whissi> The only thing I am unclear is /var/cache/distfiles vs
         /var/cache/<some-sub-folder>/distfiles...
<ulm> or /var/games
<leio> I don't like the color of "db" vs "lib" and am not sure binpkgs are
       exactly reproducable to be suitable for cache. I'd be happy with
       /var/lib/repos/gentoo and the rest as mentioned above.
<K_F> vote on original first and then see if we need follow-up votes?   [20:58]
<leio> as a side question, how soon is our next meeting; second tuesday
       already?
<Whissi> leio: Think about clients... I you are on a client using binhost, you
         will fetch packages from a binhost. This is the same location... and
         here, /var/cache makes sense.
<leio> second sunday*
*** rich0 (~quassel@gentoo/developer/rich0) has joined channel #gentoo-council
*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +v
    rich0
<ulm> K_F: yes, let's vote on the proposal above
* K_F yes
* leio no
<ulm> and if it's rejected we can have separate votes on the single paths
* ulm yes
* dilfridge yes
* slyfox yes
* Whissi yes                                                            [20:59]
<ulm> WilliamH: ^^
<WilliamH> one sec                                                      [21:00]
* WilliamH yes
<slyfox> i find it unusual that portage or releng team did not just pick some
         default path on their own. no spec should require using static path
         anyway. but if it takes concil to decide on a path then sure.
                                                                        [21:01]
<dilfridge> it's the usual gentoo problem
<ulm> I count 6 yes votes and 1 no vote
<WilliamH> Whissi: sure. that could happen, but there was too much bikeshed
<ulm> motion passed
<dilfridge> if anyone *but* the council makes a decision, someone else will
            start screaming.
<WilliamH> That's why we ended up with it.
<dilfridge> one day we'll have to sign up on bash updates...            [21:02]
<K_F> dilfridge: we already do.. in EAPIs
<ulm> slyfox: it's only the default paths anyway
<dilfridge> right
<slyfox> ulm: exactly :)
<ulm> I guess we should have the portage team make the announcement, once
      they've updated
<Whissi> Well, it affects documentation so an official decision make sense in
         this case, not?
<ulm> oh, one more point
<ulm> name of the snapshot                                              [21:03]
<ulm> curently it's portage-yyyymmdd or so
<dilfridge> gentoo-....
<ulm> change it to gentoo-repo-yyyymmdd?
<K_F> wfmk
<slyfox> sounds ok
<WilliamH> ulm++
<mgorny> i think infra was already planning on changing it to gentoo-YYYYMMDD,
         with fallback symlink
<Whissi> +1 for gentoo-... no need for "-repo" suffix I think.
<WilliamH> mgorny++
<WilliamH> both sound ok to me                                          [21:04]
<K_F> gentoo is more than just the ebuild repository
<mgorny> we already name it gentoo-YYYYMMDD for squashfs
* WilliamH doesn't really care either way
<leio> I hope they make sure sufficient testing of migration paths and such is
       conducted before committing...
<ulm> ok, quick vote on "gentoo-" please
* slyfox yes                                                            [21:05]
* Whissi yes
<mgorny> K_F: the idea is to have <repo_name>-<date>
<mgorny> something that can be used for other repos as well (possibly
         including future official gentoo repos
* K_F yes
* leio yes
* ulm yes
* WilliamH yes
* dilfridge yes                                                         [21:06]
<ulm> unanimous
<ulm> let's move on
<ulm> Explicit CoC agreement for members of special projects
<ulm>
      https://archives.gentoo.org/gentoo-project/message/fd06589b97e2d53162b23342f4dceec5
<WilliamH> That's really unnecessary
<Whissi> What does that mean? I would say anyone contributing or acting as
         member of the Gentoo community must agree on CoC.              [21:07]
<WilliamH> Whissi++
<slyfox> CoC is the
         https://archives.gentoo.org/gentoo-project/message/fd06589b97e2d53162b23342f4dceec5
         specifically, right?
<K_F> Whissi++
<slyfox> gentoo's CoC is very handwavy and informational. there is not much to
         agree to
<ulm> slyfox: yes, that's my url from above?
<slyfox> gah, sorry                                                     [21:08]
<slyfox> https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct
<WilliamH> slyfox: sadly you are right.
<WilliamH> slyfox: that's another topic for another time though.
<slyfox> ok
<ulm> anyone who wants to in favour of the proposal?
<ulm> *speak
<slyfox> just making sure vote does not mean much :)
<ulm> motion: a) Make explicit agreement with CoC mandatory for being part
      (i.e. also existing members) of Comrel, Infra, Recruiters and QA.
                                                                        [21:09]
<ulm> please vote
* K_F no
* ulm no
* slyfox no
* dilfridge abstain
* WilliamH no
* Whissi no
* leio no                                                               [21:10]
<ulm> 6 no votes, 1 abstention
<ulm> motion doesn't pass
<ulm> I think we don't need to vote on b) In concordance with a) make explicit
      agreement an (unenforced) part of the first Council meeting.
<WilliamH> ulm++
<Whissi> Do we respond to those requests?                               [21:11]
<ulm> but of course, I fully agree with and support the CoC
<K_F> Whissi: it is in summary
<Whissi> OK.
<ulm> next?
<dilfridge> next;                                                       [21:12]
<ulm> open bugs
<ulm> K_F: any progress on bug 637328?
<willikins> ulm: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated";
            Documentation, GLEP Changes; IN_P; mgorny:security
<K_F> ulm: some, but not ready yet
<ulm> k
<ulm> bug 661504
<willikins> https://bugs.gentoo.org/661504 "GLEP 1: Small update to reflect
            current practice"; Documentation, GLEP Changes; CONF; ulm:glep
<ulm> we've removed the requirement that glep must be discussed on gentoo
      forums                                                            [21:13]
<slyfox> acknowledged
<K_F> good
<ulm> by decision of glep editors, so just for the record here
<dilfridge> ack, sounds good
<Whissi> OK.
<ulm> I'll close the bug then
<K_F> but yes, each GLEP change should be mentioned like this in council
      meeting                                                           [21:14]
<ulm> bug 661058
<willikins> ulm: https://bugs.gentoo.org/661058 "GLEP 63 updates @ Jul 2018";
            Documentation, GLEP Changes; CONF; mgorny:glep
<ulm> bug 659894
<willikins> ulm: https://bugs.gentoo.org/659894 "GLEP 77: Gentoo General
            Resolution"; Documentation, New GLEP submissions; CONF;
            mgorny:glep
<ulm> ^^ both discussed in previous items
<ulm> bug 642072
<willikins> ulm: https://bugs.gentoo.org/642072 "Joint venture to deal with
            copyright issues"; Gentoo Council, unspecified; CONF;
            mgorny:council
<ulm> no progress since last meeting
<ulm> Open floor                                                        [21:15]
<ulm> anything for open floor?
<mgorny> ulm: what was the state of last review of copyright glep?
<dilfridge> trustee election results just got out fyi
<K_F> seems it was a mis-send with encrypted files though
<slyfox>                                                                [21:16]
<ulm> congrats to robbat2, antarus, bman, and prometheanfire
<mgorny> K_F: better encrypted than with confirmation ids ;-)           [21:17]
<K_F> mgorny++
<dilfridge> hrhr
<ulm> mgorny: as I said, no progress on the copyright GLEP
<ulm> but I'll start working on it again now, with new council and trustees
                                                                        [21:18]
<mgorny> ulm: yes, please try to get it for the meeting 1+ mo from now ;-)
<ulm> looks like there are no further items for open floor              [21:19]
<mgorny> i think that's the last big thing on my list
<WilliamH> Just a general comment...
<WilliamH> about the comment above wrt if someone else makes a decision
           besides us people scream..
<WilliamH> In theory that's right, developers and teams can make their own
           decisions...                                                 [21:20]
<WilliamH> We can support decisions that developers make maybe, by deferring
           to the appropriate team if something gets put on our agenda.
                                                                        [21:21]
<dilfridge> yes that is true
<WilliamH> In other words, just vote to allow x team to make the decision.
<WilliamH> So that's another option maybe.                              [21:22]
<dilfridge> in terms of wording yes, in terms of workload no
<dilfridge> but I'm all for it
<WilliamH> dilfridge: ?
<WilliamH> What do you mean in terms of "workload" no
<dilfridge> well things still end up with the council that way
<dilfridge> just the next time maybe not                                [21:23]
<K_F> we have done so with qa from time to time
<dilfridge> yes
<WilliamH> That's all I had, just a general comment.                    [21:24]
<mgorny> Whissi: i would like to ask you to reread the first paragraphs of
         your manifesto,
         https://archives.gentoo.org/gentoo-project/message/82745566f899431777b6fced00f27e4b
<ulm> mgorny: I think that doesn't belong here
<ulm> so, no further points?                                            [21:25]
* dilfridge wants to have dinner
<K_F> ulm: thanks for chairing
* ulm bangs the virtual gavel :)