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