Log for 20180211 meeting.

1 files changed, 445 insertions, 0 deletions

diff --git a/meeting-logs/20180211.txt b/meeting-logs/20180211.txt
new file mode 100644
index 0000000..e44bfcc
--- /dev/null
+++ b/meeting-logs/20180211.txt
@@ -0,0 +1,445 @@
+*** ulm (~ulm@gentoo/developer/ulm) has changed mode for #gentoo-council to +m
+<ulm> let's start
+<ulm> agenda is here:
+      https://archives.gentoo.org/gentoo-dev-announce/message/5661c77c0017ec48fa97eb62eb7db316
+                                                                        [19:01]
+<ulm> roll call
+* tamiko here
+<ulm> !proj council
+<willikins> (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm,
+            williamh
+* K_F here
+<prometheanfire> o/
+* WilliamH here
+* mgorny here
+<tamiko> dilfridge should be back momentarily.                          [19:02]
+* dilfridge present
+<ulm> slyfox is missing too
+<tamiko> !seen slyfox                                                   [19:03]
+<willikins> tamiko: slyfox was last seen 2 hours, 4 minutes and 17 seconds
+            ago, saying "right" in #gentoo-toolchain
+<tamiko> Someone has a phone number?
+<ulm> I don't                                                           [19:05]
+<ulm> I think we should start                                           [19:06]
+<ulm> Status of nios2 and riscv
+<ulm>
+      https://archives.gentoo.org/gentoo-project/message/a5127b9dfdd5e6537f8293d204befe12
+<mgorny> https://bugs.gentoo.org/644754
+<WilliamH> Is there anything new there?
+<mgorny> yes and no                                                     [19:07]
+<dilfridge> only that the riscv glibc maintainer supposedly turned up at the
+            fosdem booth and asked about becoming a gentoo dev
+<K_F> think the only thing new is nothing has happend since last time, except
+      for glibc interest in riscv for a prospective developer.. but I'd say
+      removing it doesn't change that as it opens up clean slate for anyone
+      actually wanting to implement riscv
+<mgorny> there was no reply from vapier or anyone interested in working on
+         this
+<ulm> I'd say remove them for now
+<K_F> and doing it right, with team etc at that point                   [19:08]
+<ulm> can be readded quickly if necessary
+<dilfridge> but I wasnt there at the time, and nothing else happened in the
+            meantime
+<mgorny> they're merely copies of some other old profile
+<dilfridge> arrgh
+<dilfridge> there's something wrong with my internet connection
+<mgorny> so if someone wanted to do it, he can copy more recent version of
+         that profile
+<WilliamH> ulm: ++
+<ulm> mgorny: can you come forward with a motion to vote on?            [19:09]
+<dilfridge> sorry I might drop out suddenly                             [19:10]
+<mgorny> motion: 'remove nios2 & riscv from profiles/, providing a clean slate
+         for anyone wishing to readd it'?
+<dilfridge> my internet connection is going on/off all the time, with any tcp
+            connection breaking down within a minute or so              [19:11]
+<mgorny> there are no keywords to be removed, so i guess 'profiles/' covers it
+         all
+<K_F> mgorny: "if anyone wishes to readd it" ?
+* slyfox is back
+<dilfridge> anyway
+<tamiko> \o/
+<dilfridge> removing works for me
+<WilliamH> wfm
+<mgorny> K_F: sure, maybe with 'properly'
+<K_F> I prefer without properly actually
+<K_F> too much of a juddgement on current state, which isn't necessary in this
+      context                                                           [19:12]
+<mgorny> anything that removes them works for me ;-)
+<ulm> mgorny: how about "remove nios2 and riscv from profiles/ due to
+      inactivity and missing keywords in the tree, providing a clean slate if
+      anyone wishes to readd them"
+* dilfridge wonders if running a wlan router with firmware date (Jul 31 2008
+  22:32:30) is a good idea
+<K_F> ulm: wfm
+<prometheanfire> dilfridge: very safe and stable
+<mgorny> ulm: not sure if it doesn't remove focus from the fact that it has no
+         arch team to contact                                           [19:13]
+<K_F> the only place I see riscv mentioned except in profiles is actually
+      eclass/toolchain-funcs.eclass
+<dilfridge> right
+<tamiko> Let's just vote on removing the current profile stuff.
+<dilfridge> the problem is primarily "no team"
+<mgorny> yeah, without extra rationale in vote
+<K_F> not sure if we want to mention that or restrict removing the profile
+      (maybe without the dir reflection but generic profile mention?)
+<mgorny> rationale can be added to summary/log
+<ulm> yep, rationale will be in the summary                             [19:14]
+<mgorny> K_F: the dir was supposed to catch arch.list which is not strictly
+         part of profile
+<ulm> so please vote: "remove nios2 and riscv from profiles"
+* tamiko yes
+* dilfridge yes
+* K_F yes
+* slyfox abstains
+* mgorny yes
+* ulm yes
+* WilliamH yes                                                          [19:15]
+<ulm> anything else on this topic?
+<K_F> not as far as I can see
+<ulm> next then, Mailing list posting restrictions
+<mgorny> i don't think so
+<ulm> actually, same e-mail from mgorny                                 [19:16]
+<WilliamH> cancel the ml restrictions.
+<ulm> what is the status there?
+<K_F> I stand by the previous vote at least, going back and forth sets a bad
+      precedence
+<mgorny> nothing has happened since the last meeting
+<ulm> K_F: +1
+<mgorny> only a few people requested +v on list
+<WilliamH> I voted against them originally and think they send a bad message.
+                                                                        [19:17]
+<mgorny> and there were no new major incidents on -dev
+<ulm> mgorny: for now, yes
+<K_F> decision on restriction can't be based on the mood of the day and actual
+      behavior
+<ulm> that may change at any moment, though
+<WilliamH> We saw the reaction against the restrictions when they were
+           announced.
+* mgorny doesn't have a strong opinion either way                       [19:18]
+<WilliamH> The decision was based exactly on that.
+<ulm> in the past, it tended to come in bursts, with long quiet periods
+      inbetween
+<K_F> that way we'll always be reactive , and things likely have calmed
+      again.. I believe the whitelisting is a good balance between openness
+      for non-devs and the expectations listed by devs
+<K_F> in particular given it is only for the -dev list
+<mgorny> prometheanfire was working on moderation support
+<K_F> that was also discussed during last meeting, so nothing new there
+                                                                        [19:19]
+<WilliamH> imo this is more under comrel and the council shouldn't be doing
+           things that affect the entire community.
+<mgorny> but there's not much progress since
+<K_F> personally I don't believe in moderation
+<prometheanfire> K_F: only the old ways for you? :P
+<mgorny> except that there's no real agreement on how would moderation work
+<K_F> WilliamH: defining scope of mailing list is council territory
+<K_F> prometheanfire: if old ways is responsible behavior by controlling who
+      can post instead of per-message cencorship, yes                   [19:20]
+<K_F> that is just a work burden, and an oasis of conflict
+<prometheanfire> the new email system would allow for moderation, emails would
+                 have to be coppied by the mail server and sent to the old
+                 backup system as mailman3's backups are currently not
+                 compatible with our archiving
+* dilfridge reboots router and modem
+<ulm> anyone wants to come up with a motion?                            [19:21]
+<K_F> in any case, I don't see any pertinent new information since last vote,
+      so no reason to do another vote on the matter                     [19:22]
+<tamiko> Let's postpone this discussion for now.
+<mgorny> postponing won't help
+<mgorny> the problem is that users are misinformed that they can't post when
+         they can
+<prometheanfire> I won't impliment a system that won't be used
+* WilliamH motions that we cancel the restrictions
+<mgorny> so i think we should do another confirmation yes/no vote
+<tamiko> We decided that the mailing list will be developer-posting only with
+         whitelist.
+<dilfridge> I have no problems with implementing the posting restriction now
+<mgorny> if 'yes', then we enforce the restrictions and explicitly request
+         infra to enable them
+<tamiko> Why haven't we put at least the first part of it into action?
+<K_F> without any new information, a re-vote sets bad precedence
+<mgorny> if 'no', then we revoke it
+<K_F> what has changed since the last vote?
+<K_F> should we expect re-votes on other issues?
+<mgorny> K_F: my vote ;-P
+<K_F> decided is decided..
+<ulm> mgorny: confirmation of which vote? there were several in the december
+      meeting
+<WilliamH> K_F: decided wrongly can be fixed with a new vote            [19:23]
+<tamiko> I agree with K_F - we have discussed the matter and decided how to
+         move forward.
+<mgorny> i have cooled down since then
+<dilfridge> mostly, what didnt happen was that someone took care of it
+<tamiko> Let's not revisit it faster than the German social democrats change
+         their mind.
+<WilliamH> mgorny: so you are suggesting that your vote last time was a
+           knee-jerk reaction?
+<ulm> tamiko: right, we may look as inconstant as the man with the beard :)
+                                                                        [19:24]
+<mgorny> i'm saying that my vote was based on the assumption that comrel can't
+         solve problems
+<WilliamH> I motion that we cancel the mailing list restrictions.
+<slyfox> "restrictions" :)                                              [19:25]
+<mgorny> and that my vote was based on the general goal of setting equal
+         rights on both lists
+<ulm> we had 3 accepted votes
+<mgorny> wich eventually didn't pass
+<ulm> 3 passed ones
+<ulm> plus 2 that didn't pass
+<ulm> I suggest that we postpone this                                   [19:26]
+<WilliamH> as mgorny  said that won't help                              [19:27]
+<dilfridge> no
+<mgorny> ulm: if we want to postpone this, we should give a clear message to
+         users
+<dilfridge> we're not the spd
+<K_F> I don't like postpoining, I propose we drop it, if new information comes
+      up we can bring it up again
+<ulm> mgorny: we have a decision
+<K_F> but as far as I can see no new information has showed up since last
+      vote, so it stands
+<dilfridge> we should actually stand by our decision
+<ulm> +1
+<WilliamH> Even if it is a bad one?
+<slyfox> then you need to implement it :)                               [19:28]
+<K_F> WilliamH: you disagreed in the vote, it was outnumbered, so yes, even if
+      you believe it is
+<dilfridge> and while things have been quiet, the discussion will just restart
+            when the next troll comes up
+<mgorny> WilliamH: even if we vote again, i expect 5:2, so no difference
+<K_F> this is a very light form of moderation, given users are permitted to
+      post with watching
+<WilliamH> Could it not be argued that closing the list violates the social
+           contract?                                                    [19:29]
+<ulm> "the council confirms its decisions taken in the 20171210 meeting about
+      mailing list restrictions"?
+<prometheanfire> K_F: I thought you didn't believe in moderation
+<K_F> which doesn't introduce significant workload, or direct censorship of
+      content
+<ulm> WilliamH: there are several open lists
+<prometheanfire> This is default deny, with whitelisting
+<K_F> prometheanfire: per-message content moderation
+<prometheanfire> I think a default accept with blacklisting would be better
+<K_F> its not
+<WilliamH> prometheanfire: ++
+<mgorny> so let's just have someone declare he'll take care of it
+<mgorny> and push our users out of confusing state
+<prometheanfire> we don't have to go with per-message moderation
+<K_F> ulm: wfm                                                          [19:30]
+<ulm> so yeah, before we vote, any volunteer for implementing the
+      restrictions?
+<K_F> it needs to be implemented by infra
+<K_F> if infra refuses to implement it we have another data point
+<K_F> and another discussion altogether                                 [19:31]
+<mgorny> prometheanfire: isn't blacklisting what comrel does now?
+<mgorny> (sorry, i seem to have some 10s lag)
+<dilfridge> blacklisting is what we have effectively now
+<K_F> mgorny: and that won't change, that is always an option
+<ulm> right, anyone contacting infra then?
+<prometheanfire> mgorny: ya, I don't see what that's insufficient for our
+                 needs
+<WilliamH> I'm with prometheanfire
+<K_F> ulm: I believe we have a bug already, if not I can liaise with infra
+<ulm> K_F: noted
+<ulm> I don't see any new facts, so not sure if discussing this further makes
+      much sense                                                        [19:32]
+<ulm> please vote: "the council confirms its decisions taken in the 20171210
+      meeting about mailing list restrictions"
+* WilliamH no                                                           [19:33]
+* ulm yes
+* K_F yes
+* mgorny abstains
+<WilliamH> mgorny: why abastain?
+<WilliamH> why abstain?
+* tamiko yes
+<mgorny> WilliamH: because i neither want to implement this, nor i want to
+         overrule council decisions                                     [19:34]
+<tamiko> dilfridge, slyfox: *ping*
+* slyfox abstains
+<mgorny> iow, leave it for people smarter than me to decide
+<ulm> dilfridge: still here?
+* dilfridge yes                                                         [19:35]
+<ulm> 4 yes, 1 no, 2 abstentions
+<prometheanfire> yes to the vote or yes to still here?
+<ulm> so the decision stands
+<K_F> prometheanfire: that is why we use different signal channel for votes
+      (/me)
+<prometheanfire> K_F: ah, k
+<K_F> prometheanfire: as opposed to aye /nay
+<ulm> prometheanfire: /me yes is a vote always
+<ulm> can we move on?                                                   [19:36]
+<K_F> prometheanfire: or ,not opposed, but rather, as an alternative to
+<K_F> not using words from regular talk for votes
+<K_F> ulm: by all means
+<ulm> open bugs
+<ulm> bug 635344
+<willikins> ulm: https://bugs.gentoo.org/635344 "[TRACKER] manifest-hashes
+            replacement"; Gentoo Council, unspecified; CONF; mgorny:council
+                                                                        [19:37]
+<ulm> any news?
+<mgorny> ulm: i think you know more than we do ;-)                      [19:38]
+<K_F> ulm: I don't see any needs for changes as thing stand
+<ulm> does this need to be assigned to the council?
+<ulm> or can we reassign to e.g. qa?
+<K_F> I believe we already discussed whether it should be re-assigend in
+      december meeting, and already then concluded it can be reassigned
+                                                                        [19:39]
+<K_F> the only thing we discussed bringing up again previously was going to
+      only 1 hash, but I don't see that as pertinent for that bug nor
+      something we need to decide on atm
+<dilfridge> we can close it and keepthings as they are now
+<mgorny> to be honest, i think we could close that bug
+<ulm> k                                                                 [19:40]
+<mgorny> it's not really something needs to be tracked anymore by the council
+<K_F> wfm
+<K_F> " 99   This is well underway and can be closed or reassigned.
+<K_F> is from december summary
+<ulm> bug 637328
+<willikins> ulm: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated";
+            Documentation, GLEP Changes; CONF; mgorny:security
+<K_F> right, we're working on that, security lead has requested to step down,
+      so it will likely be after a new security lead is elected
+<K_F> we have a meeting discusssing things including the GLEP next weekend
+                                                                        [19:41]
+<ulm> k
+<ulm> bug 642072
+<willikins> ulm: https://bugs.gentoo.org/642072 "Joint venture to deal with
+            copyright issues"; Gentoo Council, unspecified; CONF;
+            mgorny:council
+<ulm> this is in progress too                                           [19:42]
+<ulm> there were several updates to the policy draft
+<ulm> more at the joint meeting, I guess                                [19:43]
+<WilliamH> For the record, I will be appealing the ml restrictions to the
+           trustees asking them to determin whether this violates our social
+           contract.
+<WilliamH> determine
+<slyfox> thanks!
+<tamiko> WilliamH: I am at a loss what you try to achieve here?
+<WilliamH> tamiko: if it does violate the social contract I think they could
+           probably revoke it.                                          [19:44]
+<tamiko> WilliamH: Using dedicated communication channels for development
+         (like #gentoo-dev or gentoo-dev@) is exactly orthogonal to the
+         quesiton of a social contract.
+<K_F> WilliamH: it is out of scope for trustees, social contract isn't
+      impacted by this decision
+<ulm> yeah, also it's all in the open because it can be read publicly
+<WilliamH> If that's the case, I'll definitely respect it.              [19:45]
+<dilfridge> the social contract only says that we shall be open
+<dilfridge> and the mailing list is still public                        [19:46]
+<prometheanfire> doesn't say what open means, I think it means read-only
+<ulm> WilliamH: it's not open floor yet, can we end the bugs topic first?
+<WilliamH> prometheanfire: ok, if that's the case I guess that makes sense.
+<K_F> ulm++
+<ulm> bug 644754
+<willikins> ulm: https://bugs.gentoo.org/644754 "nios2 & riscv: arches added
+            without a backing arch team"; Gentoo Linux, Profiles; CONF;
+            mgorny:vapier
+<tamiko> WilliamH: Further, I would like to avoid any further incident where
+         we put the question of responsibility at test. Council and Trustees
+         should work as a team, not trying to play power games.
+<K_F> that bug is covered by previous vote
+<ulm> that one we had already, in fact
+<dilfridge> besides, WilliamH, I do not like the attitude "our majority
+            decision was bad, so I try to find someone else to override it"
+                                                                        [19:47]
+*** ulm (~ulm@gentoo/developer/ulm) has changed mode for #gentoo-council to -m
+<ulm> open floor
+<mgorny> ulm: i'm ready to pull the plug on them as soon as the meeting ends
+<tamiko> ulm: Thanks for your patience :-)
+<ulm> np :)
+<WilliamH> I feel like a bad decision was made. Mgorny was pushing it I think,
+           and he has implied that he changed his feeling about it now.
+                                                                        [19:48]
+<mgorny> btw the one new information that might be relevant is that somebody
+         mentioned that freebsd is working on a closed ml
+<mgorny> working as in actually using
+<K_F> open floor item, thank you mgorny for OpenPGP work for gentoo repository
+<mgorny> K_F: np
+<ulm> +1
+<prometheanfire> ya, that's been a long time coming :D                  [19:49]
+<K_F> mgorny: thats not new info, it was already part of available information
+      at time of vote
+<mgorny> K_F: which reminds me you were planning to audit the new changes
+<mgorny> (to glep)
+<ulm> mgorny: now speed up gemato by a factor of 10 :p
+<WilliamH> I will be quiet in the meetings about it I guess now.
+<K_F> mgorny: right, I'll see if energy level spikes a bit next week, this
+      week got hit by a flu, badly
+<mgorny> ulm: it's rather fast. disks are slow
+<K_F> mgorny: but you're referring to lifting single filesystem restriction
+<K_F> (to have that on log since we're discussing it)                   [19:50]
+<mgorny> K_F: yes
+<mgorny> ulm: in fact, it's much faster than i expected it to be. and my disk
+         isn't fast
+<mgorny> there's also expected gain when portage starts to verify on-the-fly
+<mgorny> instead of checking whole repo
+<K_F> mgorny: I like checking whole repo consistency, actually          [19:51]
+<ulm> yeah, that would be a big step
+<mgorny> but the problem with doing that is that portage has no real vfs impl,
+         and just accesses files directly in a lot of places
+*** [Arfrever] (~Arfrever@apache/committer/Arfrever) has quit: Ping timeout:
+    240 seconds
+<prometheanfire> in reguards to council and trustees working together...
+                                                                        [19:52]
+<prometheanfire> you realize the optics of a council member calling for a
+                 trustee to be removed right?
+<mgorny> so we would have to actually secure every single place when that
+         happens
+<mgorny> removing PORTDIR and ECLASSDIR is also a good step towards making
+         this actually secure
+<mgorny> (no-the-fly can't help much if ebuild can refer to any other file
+         that wasn't tested)
+<prometheanfire> it's something that the council should be made aware of
+<mgorny> prometheanfire: i'm going to withdraw this, i wasn't aware that
+         you've actually pushed the matter forward                      [19:53]
+<K_F> prometheanfire: its done as a single member, not on behalf of council,
+      so if anyone objects to it, it will be a matter for next election
+<ulm> prometheanfire: I don't think that mgorny has acted with his council hat
+      there
+<mgorny> however, i should point out 'the optics' of trustee insulting council
+         member with his trustee hat on, and then trustees requesting to work
+         together with council                                          [19:54]
+<WilliamH> Who was calling for a trustee removal?
+<prometheanfire> that's all fine, just wanted to bring it up
+<prometheanfire> mgorny: ya,it's just bad all around really :|
+<mgorny> looks pretty hypocritical to me
+<ulm> ok, before this derails completely, any other topic for open floor?
+                                                                        [19:55]
+<K_F> its not something we need to spend time on in council meeting, in any
+      case, please discuss this in other channel
+<K_F> I want to say thanks to all devs helping making FOSDEM stand great this
+      year
+<dilfridge> I think *if* we discuss this we should probably also discuss zlg's
+            mail
+<ulm> K_F: noted                                                        [19:56]
+<ulm> and +1 of course
+<K_F> making Gentoo visible at various conferences is important for perception
+      and recruiting
+<ulm> even if I wasn't there
+<K_F> we should encourage that also outside of europe (alicef is doing a good
+      job in japan etc)
+<prometheanfire> iirc we are sending people to scale
+<K_F> ulm: https://blog.sumptuouscapital.com/2018/02/gentoo-at-fosdem-2018/ /
+      https://www.facebook.com/media/set/?set=a.10156877297098812.1073741830.8059228811&type=3
+                                                                        [19:57]
+<K_F> prometheanfire: do we have a stand there?
+<prometheanfire> yes
+<K_F> prometheanfire: nice :)
+<prometheanfire> we generally do every year iirc
+<dilfridge> so who's going?
+<prometheanfire> I think nerdboy and someone else, don't remember off the top
+                 of my head                                             [19:58]
+<K_F> we can follow up on that outside of meeting, but someone sould take
+      responsibility and do a quick writeup to document it
+<prometheanfire> I think dberkholz is leading it
+<K_F> also if they want promotional material we have the source for flyers etc
+<K_F> prometheanfire: afaik he is not a current gentoo dev :)           [19:59]
+<ulm> anything else?                                                    [20:00]
+* ulm bangs the gavel
+<ulm> meeting closed
+<slyfox> thanks all!
+<K_F> ulm: thanks for chairing
+*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
+    "Next meeting: 2018-03-11 18:00 UTC |
+    https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180311T18 |
+    https://wiki.gentoo.org/wiki/Project:Council |
+    https://dev.gentoo.org/~dilfridge/decisions.html"