[21:02:53] scarabeus asked me to proxy if he's too much late [21:03:04] * jmbsvicetto has changed topic for #gentoo-council to: "Next meeting: 20110308 2000 UTC - NOW | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | 20110201 Log and Summary now available | http://www.gentoo.org/proj/en/council/" [21:03:07] should be here in 15 mins or so [21:03:15] So, who's here? [21:03:20] I [21:03:21] -*- jmbsvicetto is present [21:03:24] <- for chainsaw [21:03:24] -*- wired here [21:03:34] -*- ssuominen in form of scarabeus I guess :P [21:03:43] tempted to use my he-man nick for this meeting [21:03:50] and yes, present obviously [21:04:15] bonsaikitten: you're around, right? [21:05:40] -*- wired hums [21:05:42] so shall we start? [21:05:49] please [21:05:52] I'll chair the meeting until scarabeus shows up [21:07:44] ok guys [21:07:47] i was bit fater [21:07:51] Did Tomas send the proposed text for using the latest EAPI when comitting to the tree? [21:07:54] I can't find it [21:07:57] no i didnt sent it [21:08:02] i spent my time in that hospital [21:08:05] scarabeus: ok, I'll leave it for you then [21:08:06] so nope [21:08:19] so we will skip that step with explanation : scarabeus slacked : [21:08:24] let me find agenda list :) [21:09:01] http://archives.gentoo.org/gentoo-dev-announce/msg_cc43b3abbe1d56e7b1408c226a8820e9.xml [21:09:05] scarabeus: ^^ [21:09:10] yep [21:09:11] i have it [21:09:14] in bookmarks [21:09:15] :) [21:09:17] ok [21:09:24] Do we need anything more to vote on besides: When writing ebuilds that don't effect Portage upgrades for old machines, use the latest EAPI? [21:09:43] Betelgeuse: no just voting it on and updating devmanual so it is policy [21:09:58] i just didnt have time to write it in proper english [21:10:13] Betelgeuse: do we want to make it a bit more clear? Something along, "unless the package in question is part of the system set"? [21:10:23] + repoman warning if new version or new package? [21:10:47] alternative line of questioning [21:10:56] very, very simply phrased: why? [21:11:10] someone answer that before we proceed with voting/devmanual [21:11:22] jmbsvicetto: not all of system set is needed for the upgrades to work [21:11:44] ferringb: makes it easier for new developers [21:11:47] system set has a surprising tendrils. [21:12:07] *surprising. specifically, it can wind up pulling in/referencing a large amount of stuff [21:12:19] jmbsvicetto wanted to upgrade Python 2.6.6-r2 to EAPI="3" :) . [21:12:29] Betelgeuse: sure, but that was an exception for a "mandate", so it doesn't prevent anyone from working on packages within the system set to choose the latest EAPI if they think it's appropriate - it just "lifts" the requirement [21:12:39] as such trying to say "unless it's part of system set" is a bit daft- does this include the full graph w/ all flag permutations for system set (and it's deps) ? [21:13:23] Arfrever: I wasn't thinking about that at this point. [21:13:46] ferringb: ok, point taken. I drop my suggestion [21:14:18] I'll leave it to someone who knows how to do it to find a repoman rule that applies when it "makes sense" [21:14:20] Betelgeuse: your turn. clarify to me how this makes it easier for new developers. [21:14:38] because with the nature of the tree, they're going to have to work with all eapi's (exempting 1, which is probably going to die in the next 6 months) [21:14:40] ferringb: it clarifies my life when deprecating old eapis and support in eclasses for them :) [21:14:44] ferringb: In my view it goes the same lines as being able to "deprecate" EAPI versions [21:14:51] scarabeus: we're not talking about deprecating here [21:15:21] scarabeus: presuming that all new ebuilds will automatically be upgraded to version foo of eapi isn't likely in light of revbumps and other such also [21:15:27] and in light of eclasses. [21:15:29] ferringb: If we require people to use the lowest EAPI that has all the features new developers use then recruiting should be much more strict about knowing the differences between EAPIs [21:15:43] ferringb: If they can learn on a need to know basis it's somewhat easier. [21:15:48] Betelgeuse: if they're working in the tree, especially if they touch eclasses, they have to know eapi differences [21:15:54] -*- ferringb disagrees [21:16:03] it might be easier for them, but it's more dangerous to the tree's QA [21:16:18] ferringb: big eclass changes should be peer reviewed [21:16:26] drop the big [21:16:27] ferringb: even now it is mess [21:16:39] ferringb: depends on how you define big of course [21:16:40] minor eclass changes can still slip by that are eapi sensitive [21:16:41] people use eapi2/3 cases in ebuilds wiht eapi1 [21:16:42] and stuff [21:16:48] so it is problem even now [21:16:53] and this problem will grow [21:16:58] with numbers of eapis we introduce [21:17:11] jmbsvicetto: yes (lag ...) [21:17:12] scarabeus: not denying controlling it is an issue [21:17:31] scarabeus: what I'm specifically picking at is the justification for this "all new ebuilds must be eapi foo" as a supposed fix for that issue [21:17:52] ferringb: I wouldn't worded it as "must" but instead as "should" [21:17:59] think I pointed out fairly well that the logic that it's easier for new devs is wrong; they still need to know the eapi's that are in the tree else frankly we shouldn't be trusting their asses [21:18:08] ferringb: any reasons people shouldn't use latest eapi then? [21:18:21] jmbsvicetto: should becomes must in the hands of a few folk who want it that way ;) [21:18:25] ferringb: so instead of making it "mandatory", I think we should make it a "suggestion" [21:18:31] ferringb: they can bump eapi when changing stuff [21:18:49] wired: use what's appropriate to the eclass, appropriate to the dep chain's importance, and in relation to the stability of the eapi [21:19:07] new != better for all cases, new == different [21:19:14] ferringb: all those are obvious exceptions, but they dont cancel the generic suggestion [21:19:29] ferringb: true, but if we approve it as "should" instead of "must", whenever someone tries to force it, they can be pointed to the policy and demonstrate it's "should" and not "must" ;) [21:19:29] wired: I reiterate; what's the actual gain of it [21:19:44] jmbsvicetto: doesn't work that way. had a couple of wars with QA to that effect even ;) [21:19:51] ferringb: I don't think we should set the bar that high for people who don't work on anything core. We should rather recruit people who are aware of their skill limits than people who think they know it all. [21:20:32] Betelgeuse: "think they know it all" is not what I said. I expect them to know the formats they're dealing in. [21:20:39] these are users systems that get impacted after all [21:20:43] and we don't peer review every change [21:20:51] thus they should know the basics of what they're touching at the very least. [21:21:12] ahem i sent for peer review or at least other team members review every eclass merge into main tree... [21:21:12] it's a seperate discussion to this one [21:21:18] and it is separate issue :) [21:21:24] scarabeus: ebuilds vastly outnumber eclasses in commit count [21:21:51] even if you account for the portage "double tap" for manifest recommits ;) [21:21:54] either way [21:21:55] ferringb: I understand, but those cases can be brought to council [21:22:01] ferringb: I don't think it's important when EAPI 6 is out for all developers to know 1-5 [21:22:17] yep i agree with Peteri [21:22:43] 0-5 but any way [21:22:45] I rather strongly disagree [21:22:53] I agree with ferringb that this falls into the "deprecate" EAPI discussion [21:22:55] I'm not saying I expect people to know 8 different eapis [21:23:10] as jmbsvicetto just mentioned, deprecate/remove eapi's from the tree if you want to keep the count down [21:23:17] developers will have to know all EAPI versions in use at the tree at that time. I really hope there won't be 6, though [21:23:38] but frankly, I expect new devs to know the eapi's that are in use in the tree- this is basic litmus test of the dev's knowledge before we let them near the tree [21:23:41] ferringb: So you want to rules for selecting an EAPI when writing ebuilds? [21:23:59] ferringb: Any rule that can result in any of the in use EAPIs requires developers to know all EAPIs. [21:24:00] no ammount of arguement will convince me otherwise on the new dev angle btw, so just assume I'm being a stubborn ass on that one ;) [21:24:16] ferringb: but people opposing ot this always say "hey dont touch my eapi i am perfectly fine with eapi1 because it has all features my ebuild currently needs" [21:24:18] Betelgeuse: what I'm trying to point out here is that the ruling that's being pushed is based on non-existant reasons [21:24:27] this way we wont ever deprecate anything [21:24:46] ferringb: in any case, I still think we should drop the current policy that states that developers should use the lowest possible EAPI version that works and replace it with "developers are strongly urged to use the most recent EAPI version at the moment they commit that makes sense for the ebuild" [21:24:46] scarabeus: frankly, we've not had need, and no one has actually been tracking the usage up until recently [21:24:51] with enforcing latest version it would somehow propagate itself quite conviniently and also you can see which stuff actually is updated [21:25:03] ferringb: ahwell we did it for quite long since eapi2 [21:25:07] at least in x11 team [21:25:25] why do you think i had so much scripts around that i just bit adjusted to work with faster pkgcore ;) [21:25:27] both sides have merit here, it is easier for the new dev to only know one EAPI, it is better for the tree (and possible the dev's future) if he knows all active EAPIs beforehand - otherwise he'll have to learn it later (hopefully) [21:25:28] ferringb: Also nudging people to bump things hopefully makes them think if there's something how the ebuild could be improved. [21:25:29] erm s/x11/kde/ [21:25:30] \ [21:25:34] ferringb: Instead of copying verbatim. [21:25:52] jmbsvicetto, careful ... thats how we got the portage/python issue on old systems [21:26:31] Betelgeuse: I could be wrong, but I suspect most devs are busy dev'ing then to be looking around for ways to polish their existing stable of ebuilds [21:26:31] jmbsvicetto: What I am not really sure if that's really codified anywhere or just an opinion of some people. [21:26:33] NeddySeagoon: "that makes sense" - doing that to packages that pervent system's update, doesn't make sense to me [21:27:00] ferringb: This rule is not meant to apply to existing ebuilds. [21:27:00] Betelgeuse: I recall at one point that was written in devmanual. I haven't looked in some time, though [21:27:12] i think we should suggest using the latest eapi whenever possible to try and move forward, but the "what new developers have to learn" issue should be handled with eapi deprecation, not this suggestion [21:27:21] Betelgeuse: heh, just the -r1 that appears to add a patch :P [21:27:28] splitting a rather fin hair there [21:27:37] ferringb: that -r1 is not going directly to stable [21:27:38] *fine. sorry, keyboard's nearing time for a replacement again [21:27:45] I think we have 3 issues going around: [21:27:50] 1. deprecating "old" eapis [21:27:50] jmbsvicetto, can you always tell? Its one package today, something else next month and suddenly the update path has gone [21:28:04] 2. setting a suggestion or rule about the EAPI version to use when commiting an ebuild [21:28:28] 3. whether a non-maintainer might push an EAPI bump during a commit [21:28:41] strike #3 [21:28:52] I think some people are worried about 3. In my view, we already have a general rule about 3 and shouldn't make special rules for EAPI [21:29:01] non-maintainer pulling that without asking the maintainer is already across the line [21:29:08] indeed [21:29:22] #3 is banned [21:29:32] hi [21:29:34] expect if council asks qa to deprecate some eapi as whole :) [21:29:58] scarabeus: if deprecation of an eapi is desired... 1) gentoo-dev ml, 2) then council. [21:30:01] scarabeus: mass actions also have working policies already [21:30:04] I'm not opposed to deprecating eapis also [21:30:16] either way; potential compromise [21:30:30] the "lowest version available" thing, punt it as far as I'm concerned [21:30:38] NeddySeagoon: yes, but that raises another issue that has we've been circling around and have yet to make a decision. How strongly do we want to allow for long term system updates and what timeline do we want to set for it? The rule still in effect is 1 year, but I don't think anyone is making sure that is actually real [21:30:45] controlling the population count of which eapi's are in use, leave it up to maintainers [21:30:59] they know when it makes sense for their particular area to migrate forward to a new eapi [21:31:21] and from a PM standpoint, we're not really that hard pressed to support the variations [21:31:40] jmbsvicetto, its a related issue. Sorry for the disruption [21:32:06] ferringb: not necessarilly true, new eapi features dont ensure that devs will use them even if they are useful :) [21:32:13] NeddySeagoon: no disruption and you're right. I just meant it's a separate issue, but it's tied to EAPI usage in tree [21:32:16] wired: when the features are useful, yes [21:32:30] wired: other times we're formalizing things or adding some bit that someone in particular needs [21:32:34] eapi1 is a good example of that [21:32:41] wired: I'd argue that if an EAPI is useful, people will want to use it. [21:32:51] it was dead on arrival, and buried when eapi2 landed [21:33:03] jmbsvicetto: that's kind of my view [21:33:07] wired: Just because an EAPI as "whistles and bells" doesn't mean it's "useful" for particular developers and or teams [21:33:15] arbitrary nudging people to go to latest presumes it's greatest [21:33:26] well it should be [21:33:29] I presume not all EAPI's are created equal, let alone the PM support. ;) [21:33:39] scarabeus: yeah, reality is a whole other thing however [21:34:03] ferringb: up to this point I'd say 1 and 2 were the most useful [21:34:05] i am 8n ebuilds away from dropping support for eapi1 in cmake-utils :) [21:34:13] "When writing new ebuilds developers can choose whathever EAPI they think is the best. Using the features of the latest EAPI is encouraged."? [21:34:13] either way, I'm fine w/ striking the "must be lowest that can do what they need", but I oppose changing it to the opposite end of the spectrum "should use latest it can" [21:34:25] Betelgeuse: that sounds good to me [21:34:28] jmbsvicetto: I'd like to see folk on 3 for prefix reasons, but that's a seperate discussion [21:34:40] Betelgeuse: perhaps just adding "when it makes sense" [21:35:08] Betelgeuse: += "... except for EAPI1. it's the ginger child of the bunch." [21:35:23] pardon to any redheads for that joke. [21:35:35] ferringb: sure. 3 is very useful for prefix, but ignoring prefix, it didn't provide many useful features for me as an individual developer [21:35:42] Betelgeuse: encouraged, but not required [21:36:04] ok lads [21:36:07] 30 mins passed [21:36:12] so lets move to next topic [21:36:27] but lets agree with dropping the deprecating that lowest preffered [21:36:34] and adding something among what peteri sent [21:36:44] +1 for dropping lowest, +1 for text mentioned. [21:36:46] I agree with both [21:36:46] others? [21:36:47] +1 on Peteri's wording [21:37:06] wired: and droppping any mention to "oldest preferred"? [21:37:25] bonsaikitten: ^ [21:37:28] jmbsvicetto: yes [21:37:37] yes to both [21:37:47] hm. 20m idle on bonsai... [21:38:04] ferringb: he seems to be on a very slow link [21:38:16] a3li: ^^ [21:38:17] I'd say dropping the 'oldest' is fine as long as noone is forced to update just for the sake of updating. so betelguese's text sounds good [21:38:24] jmbsvicetto: what, moon and back? ;) [21:38:30] :) [21:38:42] ferringb: mars [21:38:55] wired: something like an hour, but I was thinking that route initially ;) [21:38:59] scarabeus: you haven't expressed your vote yet [21:39:07] ah +1 on both [21:39:30] we can say then unanimous acceptance? [21:39:36] so, 6 votes for both and we're just missing bonsaikitten? [21:39:41] oh patrick lacking [21:39:57] bonsai is irrelevant at this point vote count wise [21:40:02] scarabeus: let's move on. He can express his vote until the end of the meeting [21:40:08] extract his +1/-1 later for official total [21:40:17] ok [21:40:27] step two will be Jorge doing lot of talk [21:40:38] as he is the mastermind for the stable arches discussions :) [21:40:45] scarabeus: my talking won't be about that policy but about the discussion ;) [21:40:49] :DD [21:40:53] eeexcuses [21:40:57] :) [21:41:01] want me to start? [21:41:17] just a thought... do we have the various arch leads available? [21:41:37] jmbsvicetto: sure go ahead [21:41:45] ferringb: that would lead me to the following question: how many arches have been electing their leads as they should? [21:41:54] ferringb: i think some teams dont have lead or keep honorary one :) [21:42:11] s/arch lead/arch sacrifical lamb/ [21:42:27] I think you must have noticed all the "flodding" I did to your inboxes [21:42:29] meant moreso, someone who is active in an arch and can speak for it formally or informally [21:42:32] yeah [21:42:49] jmbsvicetto: you're being modest now :P [21:43:02] I think the discussion has brought forward a few good points that I'll try to pursue until next meeting [21:43:10] wired: ;) [21:44:32] I think the council needs to discuss with arch teams, infra and trustees if we want new hardware, hardware specs and see what we can get [21:45:29] There's also the issue of statistics and how to recruit, motivate and keep people working on arch teams [21:45:55] I don't know if you're interested in the rest of the dicussion or if it should be left for arch teams, infra, trustees and interested developers [21:46:29] i dont think all of us needs to be in loop, i honestly tried to read all those mails tho :) [21:46:35] Before we can discuss hardware, we must complete the discussion about hardware requirements [21:46:51] jmbsvicetto: soft ice cream machine is desperatly needed [21:46:53] (it's hardware) [21:47:04] I don't mind reporting back conclusions of that discussion. In any case, you're CC'ed so you can be in the loop if you want [21:47:13] ferringb: :) [21:47:57] fine by me [21:48:00] scarabeus: about the arches policies, given the current status of the discussion, I don't know if you want to hold it off a bit more, or if you want to set a few general rules that can be reviewed depending how the discussion turns out [21:48:23] s/arches policies/slacking arches policy/ [21:49:08] Does any of you want to get involved in the statistics and or developer burnout points? [21:49:23] jmbsvicetto: those things are quite interesting [21:49:30] what, to provide ourselves as examples of burnouts? ;) [21:49:32] so -project should be hit with those numbers [21:49:55] we don't have numbers yet. The discussion is about how to get those numbers [21:50:14] in any case, I think we should move some of those discussions to project to see what comes out of them [21:50:20] yep [21:50:47] unless you want any more details, I think that's what I have to say at this point about the ongoing discussion [21:51:05] jmbsvicetto: Id like to get involved with that [21:51:33] wired: whats preventing you? (sorry this just hit my mind first when you wrote that) [21:51:50] hahah [21:52:00] wired: what part? all of it? [21:52:01] (lack of) time with most of the things id like to do [21:52:28] jmbsvicetto: ideally everything, but I was referring to the statistics [21:52:36] wired: Feel free to step in at any time [21:52:42] wired: great :) [21:53:14] Oh, I forgot one point which is the testing platform / framework / whatever [21:53:38] jmbsvicetto: thats what we need the most /me thinks [21:53:44] I'll try to start a discussion from releng with infra, QA and interested developers (grobian I didn't forgot you) and then move it to the mls [21:54:09] That's something I really want to be involved in [21:54:21] have at it as far as I'm concerned. [21:54:32] +automated [21:54:35] yes [21:54:40] *automated* [21:54:57] so alles? [21:55:00] ideally every commit would have to go through that system [21:55:02] :p [21:55:19] ha-ha [21:55:24] stable tinderbox would be cool :) [21:55:29] next point? [21:55:33] stable and testing ;) [21:55:34] yep [21:55:40] thanks. work and such. [21:55:56] yeah jorge writes hell lot of mails nowdays :P [21:55:59] thanks for that :D [21:56:07] hehe [21:56:16] so QA glepie update [21:56:23] thats probably me talkking [21:56:27] so the diff: http://dev.gentoo.org/~scarabeus/glep-0048.diff [21:56:40] and ignore the whitespace, it is not part of it [21:56:57] wording was updated at fosdem to please many [21:57:15] wordings fine. [21:57:20] anyone have issues with it? [21:57:21] so some really oppsing voices against this, or can we vote on it [21:57:34] *opposing [21:57:47] (i need new keyboard, someone wants to donate me one? :)) [21:58:07] scarabeus: you can have my (soon to be) old laptop keyboard. have fun w/ the l, g, and h key. [21:58:27] scarabeus: I'm fine with that wording [21:58:31] +1 from me. [21:58:48] +1 from me obviously [21:59:00] bonsaikitten, Betelgeuse, wired [21:59:10] why was that 4-month rule removed? because the new recruiting rules imply the lead will enforce that anway? [21:59:26] because someone got bitchy about a candidate who was 3.75 months showing up. [21:59:26] the deputy thingie sounds weird and I still think the whole thing could use some rethinking, but +1 for now [21:59:32] and 4 months is an arbitrary period. [22:00:11] -*- ferringb notes the 4 months isn't going to stop someone from behaving as QA anyways [22:00:11] a3li: the idea was to drop the "time" requirement and replace it with the "knowledge" requirement [22:00:19] it just means that an actual QA member has to follow them around and back them up [22:00:37] jmbsvicetto: sounds reasonable [22:00:48] scarabeus: I still don't think it's wise to hardcode infra. [22:01:01] I don't see why Infra needs to be involved. [22:01:24] I prefer infra [22:01:47] ferringb: How does it matter who does it? [22:01:58] I'd frankly much more prefer it if QA/devrel/infra were equivalent in power, rather than lumping things in so that devrel is the decider, infra the implementer, and qa the recommendor [22:02:28] Betelgeuse: if it's not explict they can go through infra, then the channel they'll get stuck with is devrel [22:02:34] as said, I don't like that many eggs in one basket [22:02:48] ferringb: My points it should rather be anyone with ability to suspend access. [22:02:53] s/points/point/ [22:03:19] then hard code devrel or infra. [22:03:21] ferringb: I agree with Betelgeuse that leaving it up to "anyone" who can do it doesn't impose any "limites" [22:03:30] sorry, s/"limites"/"limits" [22:03:52] jmbsvicetto: I'd say to some degree it does- in the past if it wasn't codified, it defaulted to devrel [22:04:05] either way [22:04:10] I want it explicit either can do it [22:04:37] seems we're agreed, I'm just pushing for explicit "infra can pull the trigger if asked"- grok? [22:05:25] so wording should be what [22:05:37] ferringb: I agree with either one can do it [22:05:55] scarabeus: "either infra or devrel, and they don't have to agree" [22:06:20] and yes, that opens up a fun question there ;) [22:07:24] comments? [22:07:35] ... suspended by anyone with such privileges, pending analy... [22:07:36] or has all the EU folk passed out ;) [22:07:45] i was inventing wording [22:08:05] ?? [22:08:07] ...suspended by anyone with such privileges (currently infra and devrel), pending... [22:08:18] note the 'explicit' part I'm being a stubborn mule about [22:08:22] ^^ +1 [22:08:25] k [22:08:33] sounds good [22:09:01] +1 from me obviously [22:09:14] ferringb: I know this might create some "tension" in the future between QA and devrel, but I think it can also help us to react quicker in "extreme cases" [22:09:23] se upated link [22:09:39] see [22:09:51] then, there's me asking stupid questions again: why was the lead-or-two-members thing made? [22:10:11] jmbsvicetto: I'm not saying they should be at each others throats, but I don't hugely mind them being seperated and not always agreeing. I get concerned when it's concentrated in one, or they're both ran by the same person/cadre [22:10:16] a3li: quicker response iirc [22:10:23] a3li: because we can just say shut him without providing any feedback or reason [22:10:25] wired: well, there's a lead and a deputy [22:10:33] a3li: and do it later [22:10:38] scarabeus: +1 from me [22:10:44] ferringb: I understand and agree [22:11:11] scarabeus: revoking permissions without needing to provide a reason sounds prone to abuse to me [22:11:28] a3li: the reason was to speed up reaction in case the lead and deputy aren't available at one point [22:11:41] a3li: someone may abuse their rights, yes. [22:11:42] a3li: just imagine we would not have good reason, council would eat up qa for dinner in such case [22:11:54] a3li: it's a fair bet they'll get their asses spanked 5 minutes later by the rest of us however [22:12:17] (i wrote that sentence as qa member) [22:12:20] can't make it perfect, have to rely on some checks/balances [22:12:38] jmbsvicetto: well two leads is a sufficient rate of availability imo [22:12:48] a3li: in the past it wasn't [22:12:48] ferringb: how about explicitly stating action in case of abuse in there then? [22:13:23] a3li: we can update the wording if it gets abused, come on, we dont plan to suspend acess for 11 people tomorow :D [22:13:23] a3li: I don't think that's needed. Besides council being able to review the policy, any such abuses will constitute matter for a devrel process [22:13:38] that goes in line with my question 2b) what happens if QA fails to provide reasoning in these 14 days? [22:13:52] or that analysis [22:15:02] usually we don't use the what if cases in those documents so far i could see, but common sense gives us pretty angry devrel on one side, angry developer on other, and really fcked up qa in the middle [22:15:17] My opinion is that would lead to an immediate reversal of the commit privileges removal and a devrel case [22:15:38] but there are ways to deal with that already [22:15:49] where devrel already have some rules how to proceed when someone abuses power, so the qa member whom did froze it and didnt provide rest stuff is going to be deep fried [22:16:11] scarabeus: have a link handy? [22:17:04] a3li: qa fails to provide cause in 14 days, and frankly no one cares, well, there is your answer [22:17:18] a3li: qa fails to provide cause in 14 days, people care, one way or another devrel/council winds up involved [22:17:35] (by "no one cares" I mean "no one cares nor disagress") [22:18:19] ferringb: it's a bit too implicit for me as well, given that the rest of the thing is rather verbose [22:18:25] a3li: here's the thing [22:18:41] a3li: you start trying to lock everything down into rules, you provide manuevering room for trolls to play games [22:18:48] If we want a fully documented way of acting then just leave it to devrel like currently: http://www.gentoo.org/proj/en/devrel/policy.xml [22:18:50] it makes a bad situation worse [22:19:22] a3li: enough is there imo to run with it, and make it work- and if it *doesn't* work, there are feedback mechanisms implicitly in place that means people will get very, very pissed [22:19:40] said pissed people will be sorting it (devrel/council among others) [22:20:11] that's, in my experience having been around these occurences, better than trying to codify each/every scenario [22:20:13] scarabeus: Did you count the votes? [22:20:18] if you still disagree, then go read some godel :P [22:20:24] count's 4 if memory serves [22:20:31] yeah i have 4x aye [22:20:43] scarabeus: you were a +1? [22:20:44] but i preffer to have all ayes possible [22:20:50] who's missing? [22:20:51] yeah, full tally is needed [22:21:01] a3li, Betelgeuse, bonsaikitten? [22:21:01] bonsai on both votes, betelgeuse in this case [22:21:36] ah it is 3, a3li didnt vote too :) [22:21:41] so what jorge said [22:22:00] scarabeus: then were missing 4: wired? [22:22:00] jmbsvicetto, me, wired. [22:22:03] scarabeus: your vote? [22:22:10] i said previously +1 [22:22:12] so yep [22:22:21] wired: "sounds good" == +1? [22:22:29] yes +1 [22:22:31] ferringb: well, having everything set in stone is no good indeed. I find that part to be important though [22:22:36] a3li / Betelgeuse: what about you? [22:22:56] a3li: you should tangle someday with a troll who should've been a lawyer then [22:23:01] a3li: it'll break you of that view. :) [22:23:10] as for voting, is there something like like abstention? [22:23:12] ferringb: hehehe :) [22:23:16] a3li: there is :) [22:23:22] then that'll be my vote [22:23:44] mmm. crap. [22:23:48] inconclusive count [22:23:57] scarabeus: Is the text meant to say that devrel will do the follow up by their own rules? [22:23:59] oh right, 4 [22:24:04] jorge, brian, alex, tomas = yes [22:24:04] alex = abstain [22:24:07]