path: root/meeting-logs/20150310.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

10/March/2015

[20:01:03] <radhermit> roll call?
[20:01:06] <prometheanfire> hi
[20:01:10] <dilfridge> hi
[20:01:12] -*- rich0 here
[20:01:16] -*- ulm here
[20:01:38] <-> prometheanfire heißt jetzt blueness-evil-tw
[20:01:55] <blueness-evil-tw> kk, there we go
[20:02:01] <radhermit> dberkholz, WilliamH?
[20:02:19] <dberkholz> hi
[20:02:32] <blueness-evil-tw> though I guess it's better to be more official
[20:02:35] <-> blueness-evil-tw heißt jetzt prometheanfire
[20:03:19] <radhermit> someone have WilliamH's number?
[20:03:47] <rich0> I'll text him
[20:05:39] <radhermit> so... should we start?
[20:06:41] <rich0> I'd start
[20:06:47] <radhermit> ok, first issue
[20:06:52] <rich0> No response yet from williamh
[20:07:05] <radhermit> infra team staffing query from yngwin
[20:07:47] <radhermit> thoughts?
[20:07:56] <prometheanfire> so, from an infra perspective we try to avoid flybys, we don't want to maintain code that's foreign to us
[20:07:56] <dilfridge> did any of the three actually respond to that?
[20:08:40] <prometheanfire> also, aparently there was a history of people joining infra and then leaving once they got their thing in prod
[20:08:40] <rich0> Where do we want to start with this - I think there are a few angles to this topic.
[20:08:51] <dberkholz> have we heard anything from anyone involved?
[20:09:00] <rich0> There was a specific request to stick a few people on infra.  Then there is the more general topic of how can we make infra more sustainable/etc, help out, etc.
[20:09:03] <dberkholz> infra or "proposed infra"?
[20:09:32] <radhermit> personally I'd wait for the actual people to request to join infra
[20:09:37] <rich0> radhermit: ++
[20:09:39] <dilfridge> ++
[20:09:41] <radhermit> and not this proxy requesting stuff
[20:09:51] <rich0> That is my sense with the specifics - I want these 3 people on infra.  let them ask first.
[20:10:02] <dberkholz> yeah seems a lot like the issue with the games team a while back
[20:10:04] <prometheanfire> radhermit++
[20:10:06] <radhermit> and if they have and infra turned them down... then I don't know
[20:10:11] <radhermit> that's that I guess
[20:10:12] <dilfridge> I can't really take this serious if none of the three persons actually takes place in the discussion
[20:10:13] <dberkholz> let it work out the same way
[20:10:21] <rich0> If they're shot down they can potentially ask us to intervene, though obviously we're going to have to be very careful about something like that.
[20:10:25] <prometheanfire> I have a whole thing about the issue
[20:10:45] <prometheanfire> but here's my notes on this meeting (worked out with blueness) https://gist.github.com/prometheanfire/5e37dce03953c0b9557a
[20:11:01] <rich0> So, I suggest that for the specific question of the three named individuals - have them take the initiative and council does nothing for now.  I'm happy to chat about infra in general though.
[20:11:13] <dilfridge> rich0++
[20:11:24] <radhermit> what I think would help at times are more info at a regular basis from infra
[20:11:32] <radhermit> recently in the past week it's been nice of course
[20:11:44] <radhermit> but often people are in the dark a bit
[20:11:46] <dilfridge> the last developmens are very nice
[20:12:05] <dilfridge> but yes, it would be cool to have some kinda "infra news" in the gmn for example
[20:12:17] <rich0> I wonder if we can invite robbat2 to the next council meeting for some open discussion?
[20:12:26] -*- WilliamH is here late, sorry folks
[20:12:27] <_robbat2|irssi> i'm here actually
[20:12:32] <rich0> Agree infra news would be nice, and wonder if somebody might volunteer to help infra with that?
[20:12:34] <radhermit> like, can infra have a section in the GMN?
[20:12:37] <radhermit> right lag
[20:12:51] <prometheanfire> I think that would be nice
[20:13:15] <rich0> _robbat2: I'd be very interested in your thoughts.  If there are things we can do to help change the burden on infra we should do them, get foundation/outside help, etc.
[20:13:26] <_robbat2|irssi> besides people turning up with services they want us to run; an easier way to gauge demand for new services would help a lot
[20:13:45] <_robbat2|irssi> until yngwin's mail; infra was happy to have a non-official IRC bot for example
[20:13:51] <rich0> I was thinking that somehow changing infra to more of a gatekeeper/reviewer of changes with more outside contribution of code/patches/work/etc that might help.  It would separate trust/responsibility from time to contribute.
[20:14:04] <prometheanfire> we can have services on *.dev.gentoo.org
[20:14:13] <_robbat2|irssi> there is an idea i have, but i don't have the best idea of how to get it moving
[20:14:18] <prometheanfire> one issue though is running on non-infra hardware
[20:14:42] <prometheanfire> we could use our 'cloud' account
[20:14:48] <prometheanfire> it can do subusers
[20:15:00] <_robbat2|irssi> and that's, what infra can become more like a base OS/hardware management layer, and leave the actual service running to people who want to do that
[20:15:01] <prometheanfire> but would be better to just have us spin up and assign
[20:15:03] <WilliamH> _robbat2|irssi: what's your idea?
[20:15:15] <_robbat2|irssi> with the cavest, that if you leave and nobody owns your service, infra is free to turn it off
[20:15:28] <dilfridge> sounds reasonable
[20:15:30] <prometheanfire> _robbat2|irssi: I've toyed with setting up openstack as an official thing within infra
[20:15:41] <_robbat2|irssi> there have been a lot of good web services people have written to help with tree development
[20:16:11] <_robbat2|irssi> blizzy had a superb one, to check on a web interface, which of your packages by metadata.xml were over 30 days due for stable
[20:16:18] <dberkholz> _robbat2|irssi: weirdly seems like docker could be a decent answer to that
[20:16:23] <_robbat2|irssi> when he retired as a dev, he dumped us with a tarball that didn't work
[20:16:48] <prometheanfire> dberkholz: that would work as well I think
[20:17:09] <rich0> _robbat2|irssi: like the idea.  In general I'd like to see infra as more of an overseer and less as a have-to-do-everything-themselves team.  Then you can keep it small and well-trusted.
[20:17:18] <_robbat2|irssi> what i'm concerned about if we do go with that model
[20:17:23] <_robbat2|irssi> is when the owner of a service does leave
[20:17:30] <rich0> There are a lot of people who write great code but we don't always want to trust them with root/etc.
[20:17:32] <dilfridge> I'm not familiar with the technologies, but let's try to go with one that stays closest to "normal gentoo" as possible
[20:17:34] <_robbat2|irssi> there will be a lot of push on infra to just leave the old service running
[20:18:04] <prometheanfire> dilfridge: docker would need something like systemd iirc
[20:18:17] <rich0> I think we should distinguish between core and non-core, and make sure we're never 100% dependant on non-core.
[20:18:23] <_robbat2|irssi> no, you don't need systemd for docker
[20:18:25] <dilfridge> prometheanfire: if that's all I won't mind
[20:18:33] <rich0> Core should be well-maintained.  Maybe by an "infra lite" team but not by random individual devs.
[20:18:37] <prometheanfire> dilfridge: ya, doable, just mentioning
[20:19:27] <_robbat2|irssi> there is one other major point I have
[20:19:52] <rich0> So, maybe a pyramid - infra at the top with root on anything owned by Gentoo, but more of an overseer.  Then core services maintained by teams of devs more formally, under infra supervision, but perhaps with others doing the work.  Then non-core can be a zoo with random devs offering stuff, but any of that can go away.
[20:20:05] <_robbat2|irssi> and that's in keeping infra a team that is trusted and not a liability
[20:20:28] <rich0> _robbat2|irssi: ++
[20:20:35] -*- WilliamH agrees
[20:20:39] <dilfridge> ++
[20:20:44] <_robbat2|irssi> drive-by-infra-members have been a problem in the past; as have infra members that turned out to be jerks
[20:20:46] <rich0> I'd rather see a small team doing less and having complete oversight/supervisory responsbility
[20:20:52] <_robbat2|irssi> and used their infra powers for evil
[20:21:22] <rich0> You really need to have a cool head to be infra, and not be baited into using admin privs to cause trouble.
[20:21:32] <prometheanfire> I think at this point having infra manage VMs/containers for devs wanting to do semi-official services would work
[20:21:49] <dilfridge> yes, that would be very useful
[20:21:52] <_robbat2|irssi> the legal MOTD banner you see on every Gentoo was originally only on dev.g.o, to remind devs; I had to extend it to all boxes because of two infra bad apples in the past
[20:22:12] <_robbat2|irssi> and I still run willkins as a private service, because every past IRC bot has been used abusively :-(
[20:22:48] <prometheanfire> that's disapointing :(
[20:22:58] <rich0> Ironically I think what you need to be a good infra member is really just what you should have to be a good dev, but obviously the former is more critical.
[20:23:06] <radhermit> ok, so seeing as we're drifting a bit, final resolution for the original request is that individual devs should ask to join infra themselves
[20:23:17] <prometheanfire> radhermit++
[20:23:22] <ulm> +1
[20:23:24] -*- WilliamH agrees with radhermit 
[20:23:29] <dilfridge> +1
[20:23:29] <_robbat2|irssi> (unofficial +1)
[20:23:35] <rich0> Agree, infra can handle the requests as they feel best.  Anybody can appeal, but I certainly back _robbat2|irssi's general thoughts
[20:23:47] <radhermit> and can elevate the issue to the council if they think they're dneied for a bad reason or whatever else
[20:23:52] <prometheanfire> _robbat2|irssi: should we create a bug for infra managed vms and the like?
[20:23:55] <_robbat2|irssi> and i'll document some of the unofficial infra policies, about not being a jerk
[20:23:59] <prometheanfire> take it from council
[20:24:03] <dberkholz> +1 to whatever _robbat2|irssi says.
[20:24:17] <_robbat2|irssi> prometheanfire: yes, IP space is the biggest blocker there at existing sponsors, but the rackspace cloud has promise
[20:24:44] <prometheanfire> _robbat2|irssi: I'll also see about getting us more $$ if we actually start using it
[20:24:51] <prometheanfire> shouldn't be a problem
[20:24:54] <prometheanfire> but never know
[20:25:08] <_robbat2|irssi> we should justify that we're using the free allowance first
[20:25:10] <_robbat2|irssi> then ask for more
[20:25:18] <prometheanfire> just said that :P agreed
[20:25:21] <prometheanfire> next?
[20:25:24] <radhermit> do we need to vote? anyway, I think that was the majority
[20:25:27] <radhermit> next item
[20:25:35] <radhermit> Reducing/removing stable tree for some potentially lagging arches
[20:25:56] -*- prometheanfire puts on blueness hat again
[20:26:04] <prometheanfire> for ppc/ppc64
[20:26:06] <radhermit> alpha, sparc, ia64, ppc and ppc64 were mentioned in particular
[20:26:06] <prometheanfire> okay with dropping all but a set of about 100-200 core packages to stable
[20:26:11] <WilliamH> If we just flip the switch on the arch's to exp, the arch teams can do what they want
[20:26:12] <prometheanfire> wants to talk to pacho about it the path first
[20:26:17] <prometheanfire> wants to keep python / ruby - pacho may want to drop them because of blockers
[20:26:28] <rich0> Didn't we already have this conversation?  :)
[20:26:30] <prometheanfire> so in general, yes
[20:26:42] <dilfridge> sounds somehow familiar
[20:26:53] <rich0> I really would like to see the Arch leads take more responsibility for making these calls as to whether they can realistically keep up.
[20:27:02] <rich0> But, if they aren't we can...
[20:27:14] <rich0> I don't think we really vetted this whole thing out well on the lists though.
[20:27:20] <prometheanfire> that was blueness speaking as an arch member
[20:27:21] <ulm> we decided on a policy in the 20130917 meeting
[20:27:24] <WilliamH> rich0: We basically did have this conversation, but the same thing continues to happen.
[20:28:37] <ulm> alpha and ia64 keywords can be dropped on pkg-by-pkg basis already
[20:28:48] <ulm> for sparc it was a tie vote then
[20:29:10] <WilliamH> ulm: I think that policy wound up being more complex in practice than we thought it would. ppc and ppc64 haven't kept up either.
[20:29:11] <dberkholz> i have zero opinion on this as long as it doesn't affect major arch devs/users
[20:29:11] <radhermit> we could probably kick it to the lists again and see what devs/users care about what arches
[20:29:14] <-- Arfrever (~Arfrever@apache/committer/Arfrever) hat das Netzwerk verlassen (Ping timeout: 256 seconds)
[20:29:51] <radhermit> people that care should step up and help and/or we need a better automated keywording/stabilization QA process
[20:29:55] <dilfridge> gentoostats?
[20:31:37] <WilliamH> radhermit: ++
[20:31:44] <radhermit> has that ever existed in a deployed form?
[20:32:05] <dilfridge> radhermit: only on the gsoc machine
[20:32:26] <dilfridge> and it's basically unmaintained code by now :/
[20:32:41] <radhermit> right
[20:32:58] <radhermit> not surprising
[20:33:24] <dilfridge> it would also need a push first to get it somehow into stages etc bla bla (with all the usual political implications)
[20:33:36] <dberkholz> nah you'd want it to be opt-in
[20:33:44] <dilfridge> there we go
[20:33:46] <dberkholz> just document in the handbook as an optional thing to do
[20:34:18] <WilliamH> dberkholz: ++
[20:34:33] <dilfridge> my approach is "opt-in, nothing happens by default, but as long as you dont set a switch in a config file you get a FAT NAG MESSAGE "please consider enabling""
[20:34:45] <prometheanfire> ya, isn't that how debian/ubuntu do it?
[20:35:16] <dilfridge> no idea, maybe
[20:35:45] <prometheanfire> in any case, dilfridge++
[20:35:59] <prometheanfire> with the adendum of foo=no disabling the message
[20:36:06] <dilfridge> exactly
[20:36:20] <dilfridge> just that this would need a champion to polish the code
[20:36:28] <dilfridge> etc
[20:36:34] <prometheanfire> portage uses tabs :(
[20:36:38] <dilfridge> so probably it's not a short term solution
[20:37:02] <prometheanfire> right, but I think we are getting distracted
[20:37:04] <radhermit> so resolution is kicking to lists? asking for what interest there is in arches?
[20:37:23] <blueness> just got here!
[20:37:24] <radhermit> sorry lag
[20:37:33] <blueness> (reading backlog)
[20:37:50] <prometheanfire> radhermit: think so
[20:38:15] <prometheanfire> blueness: infra - have the people being put up ask for access
[20:38:25] <blueness> i see that
[20:38:27] <prometheanfire> blueness: arch dropping, kick to lists (maybe)
[20:38:44] <blueness> we have been keepign up -> ppc and ppc64 haven't kept up either.
[20:38:53] <radhermit> anything vote worthy there? I mean I assume most of us don't know the status of all those arches
[20:38:59] <prometheanfire> but I'll defer to you til we get to open floor
[20:39:22] <-- pacho2 (~pacho@gentoo/developer/pacho) hat #gentoo-council verlassen
[20:39:22] <radhermit> or who cares about what
[20:39:31] <blueness> sorry this is wierd because i came in near the end, keep proxying for me prometheanfire
[20:39:47] <radhermit> eh, we're near the middle
[20:39:54] <prometheanfire> ok
[20:40:01] <rich0> eh, we're near the start :)
[20:40:05] <blueness> !!!
[20:40:16] <prometheanfire> the next stuff is less contentious I hope
[20:40:20] <blueness> i don't know i kinda ran home after that last meeting at the college ;)
[20:41:17] <rich0> I think we really need to chat about the arch situation on list a bit more - it isn't the sort of thing we can solve on our own in one meeting
[20:41:25] <radhermit> ok so kicking to lists for that, if we need to vote go ahead (I vote yes)
[20:41:28] <rich0> Any kind of overall QA revamp is a much bigger undertaking
[20:42:55] <radhermit> ok next issue then I guess
[20:43:01] <radhermit> flagging packages that can be stabilized for all arches at the same time
[20:43:16] <prometheanfire> general good idea
[20:43:17] <radhermit> somewhat related to the previous discussion
[20:43:21] <prometheanfire> :+1:
[20:43:33] <WilliamH> radhermit: Well, there was talk at one point about adding a "noarch" keyword to cover those.
[20:43:39] <dilfridge> it's a good idea, and could take some load off the arch teams
[20:43:55] <blueness> i'm not ppc/ppc64 lead but i've been doing a lot of work there, and i'm happy to work with pacho and others, but a decision of dropping to ~arch is not a good idea there.  so this is best discussed in the lists
[20:44:04] <dilfridge> I dont like the "noarch" idea, since it brings us into more dependency problems
[20:44:06] <radhermit> really portage has unofficially support noarch keywords for a long time
[20:44:11] <radhermit> and funtoo/cros both use them
[20:44:18] <radhermit> *supported
[20:44:23] <rich0> I think it is a good idea in general.  One issue is if an interpreted script has a dependency which isn't stable on all archs
[20:44:31] <WilliamH> I don't see a problem with a noarch keyword.
[20:44:43] <dilfridge> but what I'd recommend is that a maintainer can somehow indicate "any arch can stable all arch"
[20:44:45] <ulm> noarch won't work, there are lots of issues with dependencies, masking, etc
[20:44:50] <rich0> So, maintainers will have to use care, but I think it is a good idea
[20:45:01] <blueness> do we want noarch or allarch because its = alpha arm amd64 ... x86"
[20:45:21] <blueness> actually ulm is right
[20:45:34] <radhermit> I think more needs to be looked at into the dependency chains
[20:45:39] <blueness> becuase what's ~ in one arch might be stable in another or missing in a third
[20:45:40] <dilfridge> whoever votes for allarch/noarch is hereby drafted to write the PMS specs :P
[20:45:44] <radhermit> and how they'll break if we implement noarch keywords proeprly
[20:45:47] <radhermit> *properly
[20:46:04] <blueness> radhermit, right
[20:46:08] <radhermit> portage's method has probably worked so far since it hasn't been integrated into the whole overall scheme
[20:46:12] <ulm> dilfridge: and the portage implementation :)
[20:46:30] <rich0> Can't you just make it a regular arch, and stick ACCEPT_KEYWORDS="amd64 noarch" in the profile or whatever?  What needs to change in PMS?
[20:46:32] <prometheanfire> I was thinking more along the lines of keyword in bugzi, not ebuilds
[20:46:42] <WilliamH> rich0: ++
[20:46:56] <dilfridge> rich0: imagine a noarch package gains a new dependency
[20:47:00] <rich0> I'm fine with the bugzilla approach as well
[20:47:03] <dilfridge> that can cause massive pain
[20:47:06] <ulm> rich0: it will still break the dependency tree
[20:47:18] <rich0> dilfridge: if it gains a new dep, then check that the dep is stable on all archs, and if not, remove the noarch keyword
[20:47:27] <prometheanfire> ya, noarch as a keyword in an ebuild seems to me to invite pain
[20:47:39] <dilfridge> let's keep it simple for now
[20:47:46] <ulm> adding a bugzilla keyword is fine
[20:47:52] <radhermit> but anyway, the request was specifically about just adding a bugzilla keyword
[20:48:02] <ulm> but we need to define what are arch independent packages
[20:48:11] <dilfridge> let's find a way for a maintainer to signalize "this package is arch-independent, and the first arch to stabilize may stabilize for all"
[20:48:13] <radhermit> which is fine and shouldn't need council involvement really imo
[20:48:17] <prometheanfire> bugzi-keyword++
[20:48:41] <WilliamH> dilfridge, ulm: The dependency issues are the same for noarch vs any other arch, especially if you add noarch to the accept_keywords...
[20:48:57] <dilfridge> not really
[20:48:57] <blueness> but we really don't need a noarch/allarch keyword,  why don't we just enact some general rule like all dev-python can be stabilzed for all arches at once
[20:49:26] <blueness> i mean i know there are exceptions but if its a pure python package, it should work on all machines with python
[20:49:32] <prometheanfire> WilliamH: from what I see, if that keyword is set in the bug, then it isn't ALL arches, just those marked ~ in the ebuild and cc'd in the bug
[20:49:36] <blueness> this would fix a lot of the blockers pacho is htting
[20:49:36] <dilfridge> WilliamH: not really, since the party who stabilizes will still have to run repoman and check that the individual stable keywords work out
[20:49:56] <WilliamH> dilfridge: sure, but don't we do that anyway?
[20:50:11] <dilfridge> WilliamH: we do, but each arch on its own and it takes time
[20:50:24] <radhermit> all dev-python can't be stabilized for all arches at once... C extensions? etc :)
[20:50:32] <prometheanfire> we do, but this policy means that and arm arch member could stablized for ppc
[20:50:33] <dilfridge> WilliamH: this way, when such a package is stabilized by amd64 they can do the rest too
[20:50:55] <blueness> radhermit, i'm aware, i have one of those that i'm upstream on, but on the minor arches we can catch those after the fact
[20:50:58] <dilfridge> "all dev-python" does not work, the same way as "all dev-perl" does not work
[20:51:07] <dilfridge> since many of those have c / c++ code embedded
[20:51:11] <ulm> for python stuff, can't there issues with byte order and word length?
[20:51:30] <ulm> for app-emacs there certainly are
[20:51:31] <blueness> oh, yeah mayeb
[20:51:52] <dilfridge> it must be maintainer's decision in the end... for example I'm not too much worried about everything that is pure perl
[20:52:01] <radhermit> really it would have to be ebuild by ebuild
[20:52:20] <dilfridge> so basically we need a place to record that maintainer opinion
[20:52:31] <blueness> okay but how would we allow maintainers to mark packages where we say all archs to be stabilized at once?
[20:52:37] <radhermit> anyway, getting off topic
[20:52:44] <blueness> so if amd64 stabilizes they all do
[20:52:48] <blueness> radhermit, sorry
[20:53:20] <radhermit> we need to vote about bugz mods?
[20:53:25] <radhermit> I vote yes
[20:53:29] -*- WilliamH yes
[20:53:39] <dilfridge> does that make sense?
[20:53:42] <prometheanfire> yes
[20:53:49] <ulm> radhermit: what is the motion?
[20:54:01] <WilliamH> The keyword for bugz should probably be allarch though
[20:54:08] <rich0> ulm: ++
[20:54:20] <radhermit> motion: adding an all arch keyword to bugz
[20:55:01] <dilfridge> STABLEREQALL, "means: the first arch to stabilize may stabilize for any additional arch too"
[20:55:07] <dilfridge> ^ is this what you mean?
[20:55:13] <radhermit> to allow stabilization of all arches for icons/themes/etc by ATs
[20:55:19] <prometheanfire> dilfridge: that's what I thought this was
[20:55:20] <radhermit> yes
[20:55:35] <dilfridge> how do we treat hppa?
[20:55:44] <prometheanfire> dilfridge: distraction?
[20:55:59] <dilfridge> ^^
[20:56:01] <ulm> dilfridge: why should there be any special case for hppa?
[20:56:11] <dilfridge> okok just asking
[20:56:33] <radhermit> I really dislike typing with 15 seconds of lag :P
[20:56:46] <radhermit> so, any issues with the motion?
[20:57:05] <dberkholz> but how do we treat m68k
[20:57:22] <prometheanfire> dilfridge: if only I could kick :P
[20:57:28] <dilfridge> dberkholz: we ignore it since from our perspective it is ~arch only
[20:57:33] <WilliamH> dberkholz: ?
[20:57:34] <prometheanfire> dberkholz: for you
[20:57:36] <dberkholz> just trolling
[20:57:37] <prometheanfire> not dilfridge
[20:57:52] <dilfridge> heh
[20:57:56] <WilliamH> heh
[20:57:56] <dilfridge> back to the motion!
[20:58:04] <radhermit> all stable profile arches only yes
[20:58:14] -*- dilfridge yes
[20:58:22] -*- WilliamH yes
[20:58:25] -*- radhermit yes
[20:58:31] <dberkholz> abstain
[20:58:34] -*- prometheanfire yes
[20:58:37] -*- ulm abstain
[20:58:57] -*- rich0 yes
[20:59:19] <radhermit> passed
[20:59:25] <radhermit> next item
[20:59:36] <radhermit> Combining various keyring related USE flags into one global flag
[20:59:42] <radhermit> if we're quick ;)
[21:00:01] <prometheanfire> are these truely doing the exact same thing?
[21:00:10] <prometheanfire> I don't think they are
[21:00:13] <prometheanfire> -1
[21:00:39] <ulm> defer to lists, I would say
[21:00:48] <ulm> or to affected teams
[21:00:58] <prometheanfire> it reduces the modularity gentoo offers imo
[21:01:24] <radhermit> I agree
[21:01:31] <radhermit> probably needs more discussion on the list
[21:02:46] <radhermit> motion: defer to lists and related teams
[21:02:48] <dberkholz> gotta roll out folks, at a conference and i have a thing starting 2 minutes ago
[21:03:17] <radhermit> roll out with bug #503382 then ;)
[21:03:19] <willikins> radhermit: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
[21:03:20] <ulm> dberkholz: heh, but next topic is yours :p
[21:03:24] <dilfridge> heh
[21:04:37] <radhermit> so yeah, open floor then I guess
[21:05:14] <prometheanfire> I have a potential dev who wants to keep his name private
[21:05:26] <prometheanfire> NP-Hardass: hi
[21:05:37] <NP-Hardass> o/
[21:05:43] <dilfridge> talk to the trustees
[21:05:43] <radhermit> we already have one/some of those
[21:05:59] <dilfridge> they need to say "it's ok" on the recruitment bug
[21:06:01] <prometheanfire> ok, that's the place to get 'approval' for that then?
[21:06:04] <radhermit> anyway, I have to leave as well
[21:06:08] <prometheanfire> kk
[21:06:12] <ulm> trustees should know the real name
[21:06:24] <ulm> e.g. in case of copyright issues
[21:06:36] <prometheanfire> NP-Hardass: sound good?
[21:06:50] <radhermit> so I'll hand over the gavel to whoever else if you need to continue discussing stuff, (the lag is killing me) :P
[21:06:50] <NP-Hardass> I emailed the trustees, Betelgeuse said that they have had previous cases where they privately held the name.  I responded to him that I was content with that arrangement.
[21:07:02] <dilfridge> then things should be fine
[21:07:12] <prometheanfire> NP-Hardass: just prod when you have a dev bug so they can ack that agreement
[21:07:14] <dilfridge> make that arrangement and let trustees confirm it on the dev bug
[21:07:34] <NP-Hardass> Willdo.
[21:07:46] <dilfridge> ok
[21:07:50] <prometheanfire> anything else?
[21:07:51] <dilfridge> actually I have something
[21:07:52] <NP-Hardass> Thank you ^_^
[21:08:16] <dilfridge> could we make a "friendly prod" towards our foundation friends to get the finance statements updated?
[21:08:29] <dilfridge> last published financial summary is 2012
[21:09:43] <dilfridge> and sometimes it would be, kinda, useful to know how much money is there...
[21:11:12] <antarus> we have infinite money man
[21:11:17] <dilfridge> yeah
[21:11:23] <antarus> but yeah, need to ping quantumsummers
[21:11:26] <antarus> he has been mia lately
[21:11:28] <dilfridge> can I have 0.1% of that then? :D
[21:11:57] <prometheanfire> antarus: a google of money?
[21:12:27] <K_F> prometheanfire: I take it you mean googol
[21:12:44] -*- dilfridge would take 0.1% of that too.
[21:12:51] <prometheanfire> K_F: I know what I said :P
[21:14:10] <-- graaff (~graaff@gentoo/developer/graaff) hat das Netzwerk verlassen (Quit: Leaving)
[21:14:16] <antarus> lets not takl about work
[21:14:20] <antarus> I am busy writing a giant PM as we speak
[21:15:35] <prometheanfire> anyway, anything else?
[21:19:28] <dilfridge> seems not
[21:22:54] <prometheanfire> well, cya
[21:22:58] <dilfridge> ok then, given that radhermit handed over the gavel to noone in particular, let's close the session.
[21:23:08] <dilfridge> thanks everyone!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVKszdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d52ucP/jrpuH3GjTe6XO7GHG1bUreW
NkrLVKYkvDo+CrpErMGQooL9zWG+bViHcDy9OG7tsptzC2ArY631eAcrBVQNfXvf
SA5QvWrHBd9v2rAlahIwEpiGtjwWh3uh9Jst2wbUbtkAULYypOZ735Na26LyLFY6
HVtCZNsrS2YUR8/G8/qJE0FzSbenmNgVW1pKPlyYHBlsMeLnMWbmnXZCJNZxZMMH
gx7iFCTHX7a7ib6VvChvPm8FuN9RgSwSCXNX4SiwRcvdNa5gx2sifJjyUt+5m3CO
h12akHjn++u/hgMAOy9FqkSQ9rbxRKSuQRDNE3Tk9IvGxaWTKOLMgXYhenasR216
ZM2tzMJCEOEmigBimcOMdYSp5ipZfja9c/76sBhBZcJadO3lrUqYowDCPPa7BUna
Xp6YkYY8rzi4M+GifBYHAg/vyCB979txqzGyfFqsJc6LK1RrgbHpn2qy9p6TN/x8
JMfK6FX3OFN1U4sFjr4fbfsmhp3R6Bwq/rsEN1jK8JNsoyL++yRyYE/DNBHowDB3
G9gj8lT11KitazdfihRaRi3g4u285YEeH0+VU5U5mWOB9fDjUDeblw2SaVuJpa3b
SPndz8FAt7yF1lgCfP8GeU2x+equ10nhZ+Zmnrg6qOdQkKM2/aFyXjT1ViIC5Iti
Jnpc8tviRAfBiTENr5UM
=S/Z/
-----END PGP SIGNATURE-----