path: root/meeting-logs/20140812.txt

<ulm> 19:00 UTC, so let's start                                         [21:00]
<scarabeus> so guys, did you thought you get rid of me right? :P
<ulm> roll call
<dberkholz> hi
<ulm> blueness: radhermit: rich0: WilliamH:
<blueness> ulm, yeah lets start
<radhermit> here
<blueness> here
<ulm> scarabeus is proxying dilfridge
* WilliamH here
<scarabeus> yep                                                         [21:01]
* rich0 here
<ulm> topic: handling of bash-completion
<ulm> btw, agenda is here:
      http://article.gmane.org/gmane.linux.gentoo.project/4005          [21:02]
<ulm> discussion for bashcomp topic is here:
      http://thread.gmane.org/gmane.linux.gentoo.project/3916
<ulm> radhermit: you're member of shell-tools?
<ulm> so do you want to comment?
<radhermit> member of shell tools, but mostly use zsh :P                [21:03]
<ulm> heh
<radhermit> from what I understand, isn't it mostly waiting for someone to
            step up and do the remaining work (docs, etc)?
<WilliamH> That was my impression too                                   [21:04]
<ulm> basically, the conversion to the new scheme was started but got stuck
* WilliamH thinks the new scheme should follow upstream unless they have a
  reason not to
<ulm> and seems there are some issues that need fixing
<WilliamH> But yes, I think it just got stuck somewhere                 [21:05]
<ulm> question is if there should be any council action at this point?
<radhermit> I don't think there is much we can do
<scarabeus> well it is up to them to sort out, we should prolly match upstream
            but it simply needs to be finished
<ulm> we could encourage the team to either finish the transition, or to
      revert
<rich0> I think this just needs a champion willing to see it through.  If they
        get flak we can help with that.
<rich0> I see no issues with changing things - though there are a few proposed
        solutions.                                                      [21:06]
<blueness> i'm not sure what we are being asked to do then?
<WilliamH> blueness: same here.
<ulm> "would like to ask for action about how to finally handle
      bash-completion"
<rich0> Actually, I thought that just having everything install in the
        upstream location and using INSTALL_MASK to remove files we don't want
        made a lot of sense.
<rich0> The other option IMHO is to install in the upstream location, and then
        just point bash someplace else using a symlink-like method like
        eselect uses now.                                               [21:07]
<ulm> I dislike abusing INSTALL_MASK
<blueness> agreed
<rich0> Do people really need to pick/choose completion rules?
<blueness> INSTALL_MASK is for exceptional things
<dberkholz> yeah i'm not sure we should make the eselect module go away even
            with dynamic loading
<blueness> there's lots and its annoying to pick and choose
<blueness> dberkholz, how about on by default                           [21:08]
<dberkholz> but perhaps change the rule to enable by default
<mgorny> eselect may generate script sourced by bashrc that would disable
         completions via 'complete -r'
<dberkholz> +1 blueness
<ulm> do we agree that it is for the team to sort things out?
<blueness> ulm, yes
* WilliamH agrees
<rich0> yup
* ulm yes
<ulm> ok, that's the majority already
<WilliamH> Someone on the team should move it forward though.           [21:09]
<ulm> if there are difficulties they can come back to the council
<WilliamH> I'm not sure that we can do anything specific about that at this
           point, just commenting for the record.
<blueness> ulm, what do you mean move it forward?                       [21:10]
<ulm> more comments on this topic?
<blueness> oh oh nevernind
<dberkholz> i would recommend that the team consider keeping the eselect
            module to address user concerns but enable modules by default and
            allow disabling
<dberkholz> should make the dynamic stuff work automagically without removing
            desired flexibility
<ulm> dberkholz: o.k., noted for the summary
<ulm> next topic: phase functions in eclasses                           [21:11]
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3918
<ulm> look like there was no discussion of this in the mailing lists
<blueness> ulm, i didn't fully understand the issue is there someone that can
           speak to it                                                  [21:12]
<ulm> details are in bug 516014
<willikins> ulm: https://bugs.gentoo.org/516014 "[Future EAPI] call eclass
            phase functions from all eclasses by default"; Gentoo Hosted
            Projects, PMS/EAPI; CONF; chutzpah:pms-bugs
<dberkholz> i don't understand how concatenating phase functions could ever
            work.
<scarabeus> what I got from dilfridge and what I agree is that it is quite
            intrusive for eapi6 ; and the idea from bug 516014c7 wont work i
            think
<willikins> scarabeus: https://bugs.gentoo.org/516014 "[Future EAPI] call
            eclass phase functions from all eclasses by default"; Gentoo
            Hosted Projects, PMS/EAPI; CONF; chutzpah:pms-bugs
<dberkholz> running unpack and patch 5 times in a row?
<WilliamH> I would rather go the other way to be honest -- turn off
           export_functions and require the ebuild phase functions to run the
           eclass phase functions.                                      [21:13]
<rich0> I have to agree with ciaran here - better to just do utilitiy
        functions
<rich0> WilliamH: ++
<dberkholz> but i could see a use case for repoman warning on non-explicit
            calls with multiple fulfillers
<ulm> I suggest that we push this back to the -dev ML for discussion
<ulm> before we take any action on it
<rich0> I mean, ebuilds that contain no content are amusing, but...
<radhermit> yeah, I don't think it got much discussion on the lists yet
                                                                        [21:14]
<ulm> radhermit: none at all, it seems
<WilliamH> What are the rest of your thoughts about going the other direction?
<blueness> why do we need phase functions?  can we just call ordinary
           functions from eclasses and get the same results?
<WilliamH> e.g. no more export_functions?
<dberkholz> blueness: why do we need default functions at all, even
            eapi-provided ones?
<dberkholz> because it makes life easier
<rich0> I'd be interested in whether some projects would be overly burdened by
        having to call the eclass functions, but it seems like a good idea
                                                                        [21:15]
<ulm> WilliamH: for my packages I'd really suffer
<blueness> dberkholz, it doesn't though
<WilliamH> ulm: how so?
<ulm> many of them define no phase functions at all
<scarabeus> you guys realize it will blob quite lot all the ebuilds right :)
<blueness> scarabeus, yeah i can think of a few
<WilliamH> ulm: imo all ebuilds should have phase functions.
<rich0> The EAPI functions are really minimalistic though, and if overridden
        they go away.
* ulm thinks that the present system just works fine
<dberkholz> i think the present system could use at a minimum warnings from
            repoman about multiple definitions                          [21:16]
<WilliamH> There is too much ambiguity wrt which phase functions are  actually
           run
<WilliamH> in the current system
<scarabeus> i think there can be pitfails but it could be solved by better
            debuger showing what was actually done in each phase well for the
            dev :)
<rich0> A problem is that when everybody writes fancy eclasses that override
        phase functions, it is harder to use them in combination.
* WilliamH agrees with rich0
<rich0> If they all just exported functions, then the ebuild could string them
        together as makes sense.
<dberkholz> should PMs be more verbose about exactly which function they're
            running from where?
<scarabeus> it would certainly made the debugging issues moot           [21:17]
<scarabeus> as you would see wtf happened and investigate
<WilliamH> We have way too many eclasses that override phase functions imo
<ulm> dberkholz: there's debug-print-function already
<ulm> only needs to be enabled
<rich0> Unix principle - do one thing well.                             [21:18]
<rich0> Functions should be the same way
<scarabeus> yea but people seem not to see it ;)
<dberkholz> ulm: and also codified in every eclass etc. seems like not a great
            way to guarantee it works in the desired fashion
<ulm> o.k., any concrete motion for this topic?
<dberkholz> i kind of want a set +x but only on the function level.
<rich0> I think it does need a bit more discussion.
<radhermit> more discussion required?
<radhermit> right
<rich0> But I'm a proponent of moving away from phase functions in eclass
                                                                        [21:19]
<ulm> so, vote for "more discussion required"
* rich0 agrees
* ulm yes
<blueness> yes
<radhermit> yep
* WilliamH yes
* scarabeus yec
<scarabeus> *yes
<ulm> dberkholz?
<blueness> one thing though, is there a consensus that we want to recommend
           moving away from phase functions in eclasses?                [21:20]
* WilliamH waould recommend that
<rich0> blueness: I don't think so, but let's just take that to the list
<blueness> and should we issue a statement?
<blueness> k
<radhermit> is there an example eclass that doesn't override phase functions
            much right now?
<rich0> We can all issue opinions there...
<radhermit> because from ones I've worked with, they override things all over
            the place
<WilliamH> rich0: eutils.eclass
<ulm> blueness: I'd be opposed
<blueness> radhermit, pax-utils.eclass doesn't                          [21:21]
<WilliamH> radhermit: ^^
<dberkholz> ulm: yeah sure
<blueness> however something like toolchains.eclass is all phase funcs
<dberkholz> blueness: not from me or ulm
<rich0> systemd.eclass doesn't.
<rich0> Many do not.
<blueness> its a real mix
<dberkholz> just like eclasses themselves                               [21:22]
<ulm> that's because we don't distinguish between eclasses and "elibs"
<WilliamH> The fix for an ebuild if we stopped overriding isn't a big deal.
<dberkholz> some provide utilities that are of widespread use, others are
            intended as archetypes for an entire group of packages
<WilliamH> just write phase functions that call the ones you need
<ulm> dberkholz: exactly
<dberkholz> we shouldn't necessarily want to only have one of those two things
<ulm> can we move on please?                                            [21:23]
<ulm> next topic: games team policies
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3919
<ulm> mgorny: you want to say something?
* WilliamH does after mgorny
* scarabeus also has somehting ;)                                       [21:24]
<ulm> well, go ahead
<mgorny> just short thing
<mgorny> i believe that games team doesn't have right to enforce the policies
         they try to
<mgorny> i'm not sure what's the best thing to do here                  [21:25]
<mgorny> but i think doing nothing will result only in games progress being
         quite stalled
<mgorny> and more contributors resigning
<mgorny> so i'd like the Council at least to confirm that games team has no
         right to decide over everything being a game                   [21:26]
* mgorny ended
<ulm> they certainly don't have exclusive jurisdiction over games-* categories
<ulm> so I don't see why they should care about games ebuilds added by other
      devs
<scarabeus> to summarize what me and dilfridge thinks (I have some notes from
            him :P)
<scarabeus> * games team should never touch package they are not maintaining
<scarabeus> * games team are not mandatory to be on game packages
<scarabeus> * the game group is quite moot and rather cause issues (kill it
            maybe)
<scarabeus> * there was no public activity from the team actively on the issue
            much (or i didn't notice)
<scarabeus> * game team as is should have no power to enforce such policies
            unless they try to push them over with QA
<blueness> mgorny, where did they say that publicly and *who* said that
<dberkholz> yeah, as long as you aren't adding games herd as primary or backup
            maintainers, i don't see any problem doing whatever         [21:27]
<dberkholz> i agree with scarabeus re QA involvement being needed to dictate
            games policy as a whole
<WilliamH> Here is my thing.
<WilliamH> I understand that the games team is passively not accepting new
           members right?                                               [21:28]
<mgorny> blueness: i heard that on their channel, and you can see that from
         their activity
<scarabeus> yes
<mgorny> they kinda avoid responding in public
<WilliamH> And iirc we have an offer from calchan to work on games-related
           things in the tree right?
<mgorny> WilliamH: yes, they don't reply to join requests
<rich0> If we just let them do their own thing then that isn't an issue.  They
        just can't touch ebuilds unless maintainers add them to the herd.
<scarabeus> what if there will be games2 which gradualy try to take over?
                                                                        [21:29]
* WilliamH motions for disbanding the team on the grounds that they aren't
  accepting new members
<mgorny> what about existing game ebuilds? i.e. ebuilds which were added long
         ago, have <herd>games</herd> and see no action for a long time?
<blueness> yeah i'm not so sure about a games2
<rich0> mgorny: if somebody wants to actively maintain a package which isn't
        otherwise actively maintained, I don't see why they can't remove the
        herd if they don't want it.
<dberkholz> WilliamH: i don't see that as a valid reason as long as the
            existing team is active and competition is allowed          [21:30]
<rich0> I'm not sure why anybody would bother with a games2.
<rich0> But, in theory competition is allowed
<radhermit> imo, it seems like people are waiting for the official games lead
            to say things/accept new members and the lead probably moved on a
            long time ago
<scarabeus> rich0: if they CAN'T realisticaly join games1 :)
<rich0> This isn't QA we're talking about.
<ulm> radhermit: so they should elect a new lead
<scarabeus> come on I tried to join games team, did you EVER see me on it, I
            even gave them gamerlay with contributors they happily ignored
                                                                        [21:31]
<ulm> GLEP 39 requires one election per year
<dberkholz> i think most of the games group concerns are likely addressed by
            the sound and audio groups. i.e. direct access to hardware
<scarabeus> ulm: that is mostly ingored
<radhermit> as a games herd member, I don't care who the leader is and if
            people want to join, feel free to join
<dberkholz> err, video/audio
<bernalex> quick note: I tried sporadically to work with them & help them for
           5 years as a non-dev.
<ulm> scarabeus: it's fine if it's ignored as long as things work
<ulm> scarabeus: in the present case it doesn't                         [21:32]
<bernalex> never even got either member to acknowledge my existance on IRC or
           email.
<rich0> If we're going to let Games have some kind of forceful say over any
        game whether the maintainer wants them or not, then they HAVE to be
        open to new members and hold elections
<rich0> I'm more inclined to just let others do their own thing.  Live and let
        live.                                                           [21:33]
<mgorny> but we don't want to let them :)
<radhermit> really, I think it should be more like other herds, e.g. python
<scarabeus> actually there are two issues
<rich0> Letting everybody do their own thing is less intrusive than trying to
        push games around.
<scarabeus> 1) state of herd
<scarabeus> 2) rules herd has
<ulm> rich0: as I see it, they maintain the ebuilds in the games herd
<ulm> not all games
<rich0> ulm: works for me - and they can't go sticking ebuilds in the herd if
        the maintainer doesn't want them                                [21:34]
<ulm> right
<WilliamH> What about the concerns about the games team being non-responsive
           to new members wanting to join?
<rich0> If somebody sees a crufty ebuild in the herd and they want to pull it
        out and work on it, then we can deal with that later, but I'm
        definitely in favor of those who want to care for things vs those who
        want to neglect them...
<ulm> rich0: also I don't see what policy would allow them to enforce use of
      games.eclass or games user/group, for ebuilds they don't maintain
                                                                        [21:35]
<scarabeus> rich0: that looks wrong
<blueness> rich0, ulm i'd be okay with a statement like that "they can't go
           sticking ebuilds in the herd if the maintainer doesn't want them",
           but it would be nice if they had made such a statement publicly
           otherwise we're acting on hearsay
<scarabeus> rich0: imagine the situation with python
<rich0> WilliamH: If we limit them to the games herd and don't force people to
        put packages in the herd, then we don't have to care so much about the
        membership.
<scarabeus> if you would package against python policy then you would get
            frowned upon by everybody
<ulm> blueness: that's just normal policy, as I understand it
<scarabeus> same is for games, the complaint is that the enforced rule is
            actually bad
<blueness> ulm, then let's just re-iterated the policy for all herd     [21:36]
<rich0> scarabeus: sure, but strictly speaking the python team doesn't
        override maintainers.
<rich0> For the most part, if you ignore their policies you're just going to
        be dealing with a broken package.
<rich0> So, most devs will follow the policies because they just make sense.
<blueness> scarabeus, rich0 python herd has always asked if they can be added
           to my dev-python/* packages
<rich0> blueness: and do you feel like they are only adding negative value
        when they do?
<scarabeus> you just said it, the policies make sense to that thing so we obey
<scarabeus> if it does not we are not happy                             [21:37]
<rich0> You really only need rules when people can't get along on their own...
<blueness> rich0, no, i feel they are tracking python related stuff, but that
           i'm still maintainig
<rich0> blueness: and if the games team did the same thing, we wouldn't be
        having this discussion...
<blueness> its why i like being "second maintainer" on a lot of packages just
           so i'm on the bug cc list
<blueness> rich0, correct so games teams must be doing something else, but i
           don't see it                                                 [21:38]
<rich0> blueness: offtopic, but it would be nice if people could 'watch'
        packages without doing that.
<blueness> i wish games team had spoken up so we could just address them
<ulm> so, does anyone want to propose a motion?
<rich0> They require the use of their eclass, which establishes policies like
        games group, /usr/games, etc
<mgorny> blueness: they are too arrogant for that                       [21:39]
<blueness> yeah that's wrong
<mgorny> didn't you see mr_bones_' reply?
<blueness> vaguely recall
<rich0> ulm, I suggest we vote on limiting the games project to the games
        herd, with maintainers having the final say on whether a package goes
        in the herd.
* scarabeus would actually vote on disbanding them even
* scarabeus is really unhappy about them for years, and he knows it is bad
  from him                                                              [21:40]
<rich0> We could just provisionally vote on a few motions, then decide which
        one to go with if they're contradictory
<rich0> ie see what has support and then decide which of those options is best
<rich0> Honestly, if not all games are in /usr/games, games group, etc, then I
        don't see what the point is                                     [21:41]
<WilliamH> I have one more question...
<WilliamH> Say I put a new ebuild in the tree, in a games-* category with just
           me as a maintainer.
<WilliamH> that doesn't follow their policy.
<WilliamH> What happens?
<WilliamH> Do they leave it alone?                                      [21:42]
<rich0> WilliamH: today, or in the future?
<bernalex> one more thing, and I mention this out of personal experience: the
           games team make gentoo look bad for outsiders who want to become
           devs because they are interested in games.
<rich0> today, they would add themselves to the metadata, and fix your ebuild,
        or maybe remove it
<ulm> rich0: how about "Every developer is allowed to commit and maintain
      games ebuilds, without the need to ask for permission or review from
      games team. The games team does not have authority to override
      maintainer decisions on packages they don't maintain."
<WilliamH> rich0: currently.
<scarabeus> WilliamH: takeover or it will be removed too :) vaguely remember
<ulm> that's the first two points from mgorny's mail
<rich0> ulm: fine by me
<ulm> ^^ please vote                                                    [21:43]
<rich0> WilliamH: decent chance they'd pkgmove it
<radhermit> I think we're using "they" a bit much here though, isn't it mostly
            one person nowadays?
<rich0> are we voting?
<rich0> if so
* rich0 yes
* ulm yes
* scarabeus ok
<radhermit> sure
<WilliamH> What are we voting?
<blueness> yes
<ulm> WilliamH: "Every developer is allowed to commit and maintain games
      ebuilds, without the need to ask for permission or review from games
      team. The games team does not have authority to override maintainer
      decisions on packages they don't maintain."
<bernalex> WilliamH: they might very plausibly just remove it without offering
           any explanation.                                             [21:44]
<ulm> dberkholz? WilliamH?
<dberkholz> yes
* WilliamH yes, but that's true with any herd so that's not anything special
<ulm> WilliamH: right                                                   [21:45]
<rich0> WilliamH: yup - just clarifying policy
<blueness> ulm, we might want to say that
<ulm> blueness: noted
<ulm> not sure about points 3 to 5 from mgorny
<ulm> i.e. games group, /usr/games, games.eclass                        [21:46]
<dberkholz> that's for QA to care about
<mgorny> yes, sounds like QA could vote about it
<rich0> ulm: I think what we've done basically deals with the biggest logjam.
        Agree QA can look more at FHS/etc if they care to
<radhermit> what do other distros do these days?
<WilliamH> But, do we need to take any action wrt the games team not
           responding to join requests?
<scarabeus> radhermit: for suse/fedora we do nothing :)
<ulm> ok, so let's delegate the rest to QA
<radhermit> scarabeus: figured as much                                  [21:47]
<scarabeus> yep revision of rules should be handled by QA
<bernalex> WilliamH: if you don't, the games team will continue to reflect
           very poorly on gentoo.
<radhermit> I think we just copied what debian (or some distro) did a long
            time ago
<ulm> WilliamH: propose a motion
<radhermit> who needs to respond? I mean, I could but I'm not the leader and
            just maintain one or two emulators.                         [21:48]
<scarabeus> debian it was
<WilliamH> Who is the  games lead?
<bernalex> vapier lol
<ulm> WilliamH: vapier
<scarabeus> damn i have 7secs lag
<radhermit> no idea, vapier?
<bernalex> in practice it is mr_bones though.
<radhermit> right
<mgorny> vapier is formal but doesn't reply at all AFAIK                [21:49]
<bernalex> neither does mr_bones
<mgorny> mr_bones_ sometimes replies
<WilliamH> I'm open to suggestions for the motion... It sounds like people
           have wanted to join the team and been passively refused...
<scarabeus> we could select radhermit as temporary TL whoms job would be to
            get new members and hold elections                          [21:50]
* radhermit coughs, I solved that by asking and then just adding myself a long
  time ago :P
<radhermit> when no one responded for a while
<rich0> So, with games herd somewhat "contained" do we need to prod them on
        the membership issue, or is that moot?
<dberkholz> i don't think they need prodding.
<ulm> as was said previously, anyone can create a games2 project        [21:51]
<WilliamH> ulm: that would be a mess...
<scarabeus> ulm: and as i asked what would happen if games2 started takeover
            games1 pkgs
<bernalex> ulm: again I'd like to raise the issue of PR. competing games teams
           would make gentoo look really bad, just like the current games team
           does.
<scarabeus> the complaints would be valid if the set of rules would be
            different
<WilliamH> ulm: that's the same reason I didn't create systemd2 or something a
           while back.
<rich0> Is that like competing udev teams?  :)
<scarabeus> that IS a mess :0                                           [21:52]
<rich0> Except that udev is hardly a trivial package?
<scarabeus> ;)
<bernalex> rich0: isn't neverwinter nights the most non-trivial package in all
           of portage still lol
<blueness> scarabeus, rich0 there is a difference between just two competing
           packages and competing herds
<ulm> "the council encourages the games team to accept join requests and elect
      a lead"?                                                          [21:53]
<blueness> we have lots of competing packages which we deal with virtuals
<rich0> ulm: I think that is a good starting point.
<scarabeus> ulm: and if nothing happens?
<blueness> ulm, i like it
<radhermit> imo, people should just add themselves and try to come up with a
            consensus with regards to ideas/changes, go through and update
            docs, and go from there
<rich0> If anybody wants to join and can't, they should speak up.
<rich0> I asked about people who wanted in and couldn't join, and I got
        crickets.
<ulm> scarabeus: then we reiterate
<WilliamH> ulm: then we disband them
<blueness> radhermit, can't you speak up for the team?
<rich0> If people want to join, we can help them out.
<radhermit> my problem is I hardly do much in regards to it
<blueness> ah                                                           [21:54]
<radhermit> mr_bones is the main guy
<mgorny> well, the problem is that people don't want to join the team if
         that's going to require them to follow the policies they oppose...
<ulm> so, consensus on: "the council encourages the games team to accept join
      requests and elect a lead"?
* ulm yes
<dberkholz> sure
* WilliamH thinks we should make that stronger                          [21:55]
* rich0 yes
<radhermit> sure
<ulm> WilliamH: we start with a watchmaker's tool, the sledgehammer will
      follow later if necessary :)
<scarabeus> "The council requires games team to elect a lead and allow people
            to join"
<WilliamH> "The council encourages the games team to accept join requests, and
           asks them to elect a lead within 30 days. If they do not, we will
           disband them."
<bernalex> mgorny: I have been completely discouraged and lost all interest in
           joining the current team.                                    [21:56]
<scarabeus> bernalex: no worries you are not around i gave hope like 3 years
            ago on that :)
<ulm> ok, we have a majority for the first motion already
* WilliamH votes no for the first motion                                [21:57]
<ulm> so we could just vote on WilliamH's one
<ulm> i.e. if we make it stronger
<WilliamH> ulm my motion is:
<WilliamH> "The council encourages the games team to accept join requests, and
           asks them to elect a lead within 30 days. If they do not, we will
           disband them."
<rich0> what does the "if they do not" pertain to?  Electing a lead, or
        accepting more people?
<rich0> Assuming more want to join...                                   [21:58]
<scarabeus> i guess mr_bones_ can elect himself that should not be that tough
            so it is not as evil as it seems it just dethrones vapier
<WilliamH> rich0: hmm
* dol-sen suggests 30 days is not enough time for that
<WilliamH> I'm open to suggestions for rewording it.
<blueness> "In the absense of a lead being elected, we will consider the herd
           as disfunctional and thus disband it"                        [21:59]
<ulm> s/herd/team/
<blueness> or In the event they don't elect a lead
<radhermit> do people wanting work on games ebuilds really even want a herd
            anymore if we're moving away from centralized games munging?
<blueness> let me try again
<blueness> "In the event they don't elect a lead, we will consider the team as
           disfunctional and thus disband it"                           [22:00]
<WilliamH> I think we should ask them to give time for new people to join
           before they elect a lead...
<mgorny> radhermit: i think we ought to have a team of dedicated people to
         help contributors getting game ebuilds into gentoo
<blueness> that might not be a bad policy in general since a team without a
           lead is pretty disorganized
<ulm> blueness: time frame for this to happen? 6 weeks?
<mgorny> radhermit: we don't own many games and need users for that
<blueness> ulm, yeah 6 weeks
<WilliamH> blueness: I think there are small teams without leads...
<blueness> WilliamH, i still want your piece                            [22:01]
<rich0> mgorny: I'm fine with that, but people have to step up to be on that
        team
<radhermit> mgorny: makes sense
<rich0> I was kind of hoping to go that route, but I think most are burned out
        due to the whole conflict
<blueness> WilliamH, webapp-config is pretty leaderless there wsa only one
           incident where a leader was needed
<ulm> so please vote on: "In the event they don't elect a lead within 6 weeks,
      we will consider the team as disfunctional and thus disband it"
* blueness yes
* rich0 yes                                                             [22:02]
<radhermit> yes
* WilliamH yes
* ulm yes
* scarabeus yes
<ulm> dberkholz?
<dberkholz> abstain
<mgorny> just to be clear, do we have any rules for how team lead should be
         elected?
<ulm> 6 yes 1 abstention                                                [22:03]
<ulm> mgorny: we don't
<mgorny> e.g. can they re-elect vapier?
<ulm> sure
<scarabeus> but iirc tl must ACCEPT the offer first
<scarabeus> so no reply for being nominated for TL disqualifies you
<mgorny> i'm a bit afraid the best thing that's going to happen is a new
         inactive lead...
<ulm> scarabeus: that's common sense                                    [22:04]
<ulm> mgorny: then we can reiterate
<scarabeus> come on even status quo can be punished
<mgorny> maybe it would be indeed better to disband it, let new people join
         and elect new lead among themselves
<scarabeus> lets just give some good faith
<blueness> mgorny, and encourage new members, so we can revisit his
<blueness> this
<bernalex> there sholud be a team lead slacker rule like for council.
<rich0> mgorny: if people want to join and are being kept out, we can
        potentially shoehorn them in                                    [22:05]
<scarabeus> actually i liked my proposal to make radhermit TL and let him
            coordinate next elections
<mgorny> i mean, letting all interested people join with a free card, rather
         than into a team with disliked lead
<scarabeus> radhermit: i think you can be active there for a bit no?
<rich0> I'm fine with having an interim lead to essentially moderate new
        elections
<scarabeus> at least reading mails for 6 weeks ;)
<radhermit> heh, I can help poke things along sure
* WilliamH is fine with radhermit coordinating the election and recruiting new
  members
<ulm> we're past the one hour limit already
<mgorny> as in, 1) people join, 2) new lead is voted amongst all members
<radhermit> but I'm not anywhere close to the major contributor for games
            stuff
<dberkholz> i've gotta run after we're done with this                   [22:06]
* dol-sen agrees with radhermit as temp lead... It's what I did in portage
  last Xmas
<scarabeus> radhermit: but you are just temporary scapegoat seated by council
            so as far as you are fine by not being elected again in 6 weeks :P
<bernalex> I say offer hasufell the interim lead position...
<mgorny> no, hasufell lacks the social skills
* WilliamH motions that radhermit be the interrum lead of games until the
  elections are held
<mgorny> radhermit is a good choice
<ulm> I cannot make it next tuesday
<ulm> how about new meeting in two weeks, at august 26?                 [22:07]
<rich0> He can be the viceroy :)
<rich0> 26th wfm                                                        [22:08]
<scarabeus> he can call himself even supreme commander and drink only mojitos,
            dont care about that :D
<WilliamH> wfm
<radhermit> 26th should work for me
<scarabeus> dilfridge should be back at that point
<blueness> yep, i can make the 26th                                     [22:09]
<ulm> blueness: dberkholz: dilfridge|mobile: 26th o.k. as meeting date?
<blueness> now that i'm teaching again, i have to look at my schedule
<dberkholz> i may need to find a proxy, not sure yet
<dberkholz> but go ahead and schedule
<ulm> k
<dberkholz> oh btw
<dberkholz>
            /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20131210-summary.txt,v
            <--  20131210-summary.txt                                   [22:10]
<dberkholz> initial revision: 1.1
<dberkholz>
            /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140114-summary.txt,v
            <--  20140114-summary.txt
<dberkholz> initial revision: 1.1
<rich0> dberkholz: ++  :)
<radhermit> nice work
<mgorny> WilliamH still had one last motion
<ulm> "radhermit be the interim lead of games until the elections are held"?
                                                                        [22:11]
<mgorny> yes
<ulm> do we have the authority for this?
<dol-sen> yes
<scarabeus> i yes
<scarabeus> we should
<ulm> o.k., let's vote on this one
* ulm abstains                                                          [22:12]
* rich0 yes
* radhermit abstains
* scarabeus acks if radhermit wants it
<radhermit> I'll help things along, I just don't want to be lead in the future
<dberkholz> i don't see why we need an interim lead for 6 weeks, we need an
            election official
<rich0> best candidate for an interim lead - somebody who is short-term
<rich0> interim lead can help drum up more life for the team            [22:13]
<dberkholz> and it would be weird for him to be both at once
<rich0> accept join requests
<rich0> etc
<radhermit> how do herds do official elections?
<rich0> And if he isn't a candidate for the long-term lead, the can officiate
        the election
<rich0> radhermit: up to you to figure out, but I'd just vote by email, or on
        irc
<rich0> I don't think it needs to be secret ballot
<WilliamH> radhermit: there is no global policy
<rich0> keep it simple                                                  [22:14]
<radhermit> right, that's why I've seen
<rich0> but you can do something fancier if you want to
<radhermit> s/why/what/
* WilliamH votes yes
<ulm> so I see 3 yes votes and 2 abstentions
<ulm> who's missing?
<ulm> blueness?
<dberkholz> abstain as well
<dberkholz> and with that, i've gotta run                               [22:15]
<scarabeus> blueness: wake up you are tie breaker :D                    [22:16]
<ulm> hm? seems it's accepted
<ulm> 3 yes 0 ne 3 abstain
<scarabeus> ulm: how
<ulm> s/ne/no
<scarabeus> i thought you need 4 even with abstains
<ulm> simple majority                                                   [22:17]
<ulm> but I agree that 4 yes would be nicer
<scarabeus> ah ok
<rich0> scarabeus: if that were true there would be no point in abstain - it
        would be the same as ano
<ulm> blueness: ^^
<ulm> anyway
<ulm> radhermit: do you accept being interim lead                       [22:18]
<scarabeus> radhermit: enjoy the shiny hat then :P
<mgorny> radhermit: now, drop all the policies, quick!
<radhermit> heh
<scarabeus> lol
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: Tuesday, 26 Aug 2014 19:00 UTC |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
    http://wiki.gentoo.org/wiki/Project:Council"                        [22:19]
<WilliamH> radhermit: You may want to talk to calchan; he was interested in
           helping out the games team.
<scarabeus> gotta run myself, have fun
<dol-sen> radhermit, it wasn't bad when I assumed interim lead for portage, it
          just got busy :)
<radhermit> I'll just try to bring in new blood, start discussions about
            changing policies, and do an election after people are settled
<dol-sen> exactly
<rich0> radhermit: yup - best way to go                                 [22:20]
<rich0> focus more on building a team, so that the team can figure out what to
        do
<dol-sen> it's just with my new team, nobody wanted to be lead ;)
<blueness> sorry i just got a phone calle
<bernalex> dol-sen: radhermit: kind of comparable situations. games team is as
           low on people as portage, I would assume.                    [22:21]
<blueness> ulm, i'm okay with radhermit being in charge
<bernalex> & in 6 weeks radhermit will be benevolent dictator for life because
           nobody else wants to be team lead ;-)
<ulm> ok, so accepted with 4 yes and 3 abstentions
<ulm> and I close this meeting