path: root/meeting-logs/20180211.txt

*** 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"