path: root/meeting-logs/20170312.txt

14:05 <@WilliamH> Ok, let's get started...
14:05 <@WilliamH> agenda is here: https://archives.gentoo.org/gentoo-project/message/5d66170039af5d5e76c348a51bb32aef
14:05 <@WilliamH> roll call:
14:05  * jlec here
14:05  * rich0 here
14:05  * dilfridge here
14:05  * K_F here
14:05  * ulm here
14:06  * WilliamH here
14:06 <@blueness> hello
14:06 <@blueness> who’s chair?
14:06 <@blueness> let’s do this thing!
14:06 <@dilfridge> hrhr :D
14:06 <@WilliamH> We have a light agenda today...
14:06  * ulm admires blueness's utf-8 apostrophs
14:06 <@WilliamH> first topic:
14:06 <@WilliamH> bugs with council involvement:
14:07 <@WilliamH> bug 565566
14:07 < willikins> WilliamH: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
14:07  * blueness here
14:07 <@blueness> ulm: huh?   are yo seeing something i ‘m not?
14:08 <@dilfridge> blueness: are you on a mac by any chance?
14:08 <@blueness> yep
14:08 <@WilliamH> still no response from infra...
14:08 <@dilfridge> :)
14:08 <@K_F> WilliamH: we pinged it after the january meeting, if someone cares strongly they can follow up, but there really isn't much for council to do on it at this point
14:09 <@dilfridge>  ‘ versus ' versus ` versus ´
14:09 <@WilliamH> K_F: so we are just monitoring that then?
14:09 <@K_F> WilliamH: that'd be my suggestion
14:09 <@WilliamH> ok.
14:09 <@dilfridge> I dont care what happens in the separate rsync module
14:09 <@WilliamH> bug 571490
14:09 < willikins> WilliamH: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Documentation, Project-specific documentation; CONF; mgorny:council
14:09 <@dilfridge> that one is in all of your inboxen, but noone replied so far
14:10 <@ulm> dilfridge: looks good to me
14:10 <@K_F> dilfridge: I don't have any comment for the updated version
14:10 <@dilfridge> ok then I'll commit it
14:10 <@WilliamH> I don't have any comments either.
14:10 <@K_F> good to get rid of that bug report :)
14:10 <@dilfridge> heh, yes
14:11 <@WilliamH> bug 611234
14:11 < willikins> WilliamH: https://bugs.gentoo.org/611234 "Council vote: CVS headers and git expansion"; Community Relations, Developer Relations; IN_P; k_f:council
14:11  * dilfridge is glad that we handled that so quickly
14:11 <@K_F> indeed
14:11 <@WilliamH> Agreed
14:11 <@K_F> WilliamH: should just include the resolution and vote count in today's meeting summary and then we can close bug
14:11 <@ulm> could the motion and the result of the vote be included in the meeting's summary
14:11 <@dilfridge> yep
14:12 <@ulm> K_F: :)
14:12 <@WilliamH> yes
14:12 <@rich0> ++
14:12 <@WilliamH> bug 610990
14:12 < willikins> WilliamH: https://bugs.gentoo.org/610990 "Please create a BZ product "Gentoo Council" similar to "Gentoo Foundation""; Gentoo Infrastructure, Bugzilla; CONF; dilfridge:bugzilla
14:12  * dilfridge forgot about this completely
14:13 <@K_F> it'll be nice to have, but waiting for infra action
14:13 <@dilfridge> the council bz group already exists
14:13 <@blueness> what is a BZ product?
14:13 <@dilfridge> (and is kept updated)
14:13 <@K_F> blueness: bugzilla category
14:13 <@blueness> oh oh
14:13 <@K_F> dilfridge: yeah, but it needs to be enabled somewhere to restrict access
14:13 <@dilfridge> https://bugs.gentoo.org/enter_bug.cgi < what you select on this page
14:14 <@dilfridge> yep, same as for comrel and qa and trustees
14:15 <@WilliamH> next topic: open floor...
14:15  * WilliamH listens
14:15 <@dilfridge> so,
14:15 < mrueg> Can I get the council's position on bug 611376? Is there any immediate action required with the new ToS?
14:15 < willikins> mrueg: https://bugs.gentoo.org/611376 "New GitHub Terms of Service"; Gentoo Foundation, Proposals; CONF; ulm:trustees
14:16 <@K_F> mrueg: that is a trustee matter
14:16 <@WilliamH> That's a trustee matter.
14:16  * ulm agrees
14:16 <@jlec> I think so too
14:16 <@dilfridge> yep
14:17 <@blueness> mrueg: i warned about that but no one listened
14:17 < mrueg> K_F: so in theory we have projects that cause these issues, so it becomes a council matter
14:17 <@blueness> once your data is locked in, they change the TOS
14:17 <@dilfridge> so if they feel like burning off some calories and springing into some activity...
14:17 <@K_F> mrueg: sounds like a round-trip via QA then :)
14:18 <@WilliamH> It is also debatable whether that really affects anything... There's another discussion online about it.
14:18 <@rich0> FWIW, no other projects seem all that concerned with it, nor do fairly well-known names on the Foundation list.
14:18 <@K_F> there are debates on debian legal, but they don't seem to well informed
14:18 <@K_F> seems most of the issue is nobody want to touch it with a pole, due to the potential imapct
14:18 <@K_F> impact*
14:19 <@K_F> must say, haven't been too impressed with some of the "analysis" from these names going out protecting it
14:19 < Soap__> here's an idea, once python or some major project moves due to legal concerns, lets revisit
14:19 <@rich0> My sense is that Github may tweak the wording based on feedback.
14:19 <@dilfridge> in a way this type of muddiness is precisely what everyone was worried about in the first point
14:19 <@K_F> rich0: but do they still have your trust?
14:20 <@ulm> Soap__: the largest problem are nonfree files in our tree
14:20 <@rich0> K_F: most of them are more conservative than I am.  :)
14:20 <@ulm> and I guess other projects are not so much affected by that
14:20 <@dilfridge> debian should be mostly fine w/r to nonfree files
14:21 <@dilfridge> python probably too if the whole project is under one and the same license
14:21 <@dilfridge> shall we
14:21 < Soap__> mrueg: better move your overlay quickly!
14:21 <@K_F> yeah. it requires independent review for each project, in any case, trustee matter
14:22 <@WilliamH> ok... anything else?
14:22 <@dilfridge> put up a motion like "the council kinly asks the trustees to watch the situation carefully"
14:22 <@dilfridge> kindly
14:22 <@dilfridge> not needed, really, since that's their job anyway
14:22 <@WilliamH> Is a motion really necessary for this since we agree this is a trustee matter?
14:22 <@K_F> dilfridge: its their job to begin with
14:22 <@rich0> And the situation doesn't warrant special watching anyway, IMO.
14:23 <@dilfridge> k
14:23 <@dilfridge> something else,
14:23 <@dilfridge> http://dev.gentoo.org/~dilfridge/decisions.pdf  < this project is slowly progressing
14:23 <@WilliamH> any other topics for open floor? 
14:23 <@dilfridge> the main point of it imho is to get a keyword index
14:23 <@K_F> dilfridge: nice :)
14:24 <@dilfridge> the index is right now still a mess, but that will improve over time :)
14:24 <@jlec> dilfridge: sweet
14:24 <@dilfridge> it's reached now the point where I see the first "epoch cycles", of e.g. slacking arches discussions repeating themselves...
14:24 <@dilfridge> (hi jmbsvicetto :)
14:25 <@dilfridge> anyway
14:25 <@dilfridge> just so you know :)
14:26 <@WilliamH> anything else?
14:26 <@K_F> as another FYI; finally got around to writing up draft of security GLEP, so at least that discussion is progressing on ML, so please participate in discussion there and propose updates
14:26 <@K_F> ComRel one is down the line , but prefer to do it sequentially
14:27 <@WilliamH> last call for open floor....
14:27 <@rich0> I think Comrel could use a GLEP, but honestly I think Security is pushing it a bit.
14:27 < Soap__> dilfridge: every cycle I delay writing the mail to drop ia64/ppc/sparc to dev
14:28 <@dilfridge> rich0: well, either we say "security has no special powers", then we dont need a GLEP
14:28 <@K_F> rich0: I prefer it like that anyways as long as the project has certain tree-wide permissions, and want to restrict @gentoo.org participation on security MLs etc
14:28 <@WilliamH> Soap__: Actually that doesn't require council action if you can get the arch team members to do it.
14:28 <@dilfridge> (and security will strongly disagree with that)
14:28 < Soap__> WilliamH: which arch members :P
14:28 <@dilfridge> or we say "they do", and then they should be codified somehow
14:28 < Soap__> I never got a reply from ia64 or sparc
14:28 <@rich0> K_F: and that is why I'm not really opposed to it either
14:29 <@K_F> rich0: I agree Comrel is more important in many ways, but it is also a more complex issue so will take a bit of time and I need to get a bit more familiar, been active in security longer than comrel after all :)
14:29 <@dilfridge> rich0: for the comrel one we only just started team-internal discussion about details
14:30 < jmbsvicetto> Hi dilfridge
14:30  * WilliamH bangs the gavel
14:30 <@WilliamH> meeting closed