20:00 <@jokey> dberkholz: you've taken chair, start the show plz ;) 20:00 <@dberkholz> ok 20:00 <@dberkholz> council members, sound off 20:00 * amne looks 20:01 <@Flameeyes> I'm here 20:01 <@Betelgeuse> \o/ 20:01 <@jokey> \o/ 20:03 <@dberkholz> vapier: how's your ping? 20:04 <@vapier> hot 20:04 <@dberkholz> sweet. 20:04 <@dberkholz> first issue, new USE documentation. 20:04 <@dberkholz> it's in place, should we revert it or leave it in place and consider further changes? 20:05 -!- Maedhros [n=jc@gentoo/developer/Maedhros] has joined #gentoo-council 20:05 <@lu_zero> leave it and consider improvements 20:05 <@lu_zero> ("go agile" =P) 20:05 <@Flameeyes> as lu_zero said 20:06 <@dberkholz> anyone disagree with that? 20:06 <@amne> lu_zero++ 20:06 <@vapier> sounds peachy 20:06 <@Flameeyes> none of the concerns I've read about seems to be incompatible with the current (albeit basic) implementation 20:06 <@jokey> with it 20:06 <@vapier> that doesnt mean it was done "properly" 20:07 <@jokey> right, but still won't block further extensions of it 20:07 <@Flameeyes> vapier, I disagree but you know that already :) 20:07 <@vapier> planet.g.o is not the place for development 20:07 <@vapier> there's a development mailing list 20:07 <@vapier> use it 20:07 <@lu_zero> so point 1b, how to fix the process 20:08 <@lu_zero> Flameeyes pointed in many places that the glep process is problematic 20:08 <@Betelgeuse> it's not 20:08 <@Betelgeuse> but we do need some GLEP editors 20:09 <@Betelgeuse> old ones need updating 20:09 <@dberkholz> could you remind me what problems there were besides him not wanting to write in english? 20:09 <@lu_zero> dberkholz let me see 20:09 <@Flameeyes> dberkholz, never said I don't want to write in english, in fact, I actually do write in english more than I write in italian lately :) 20:09 <@lu_zero> - the system seems to let proposal go stale 20:09 <@vapier> people still use italian ? 20:10 <@Flameeyes> my problem on language was more that the glep review process seems to go anal on grammar more than feasibility 20:10 <@lu_zero> - writing a glep takes no much effort, getting it through more than implementing the proposals sometimes 20:10 <@vapier> Flameeyes: i wouldnt say it's anal on grammar, it's anal on being correct 20:10 <@dberkholz> one other issue i remember is that someone said that gleps never ended up getting integrated into other documentation, and you couldn't figure out what the actual result was in one place 20:10 <@vapier> you're talking about a mini-spec 20:11 <@vapier> it cant be ambiguous 20:11 <@jokey> dberkholz: that's valid though (mostly devmanual additions have been left out from what I recall on that list) 20:12 <@jokey> might be related that we have no active devmanual maintainer atm 20:12 <@Betelgeuse> Halcy0n is coming back. 20:12 <@Betelgeuse> He will hopefully do it. 20:12 <@vapier> he seems set on it 20:12 <@Flameeyes> vapier, and that's one problem, I can see why a spec is needed for big changes, but we're full of little changes for which I think a spec is an overkill 20:12 <@dberkholz> yeah, he's submitted a lot of patches to it 20:12 <@Flameeyes> and for those, being anal on correctness slows down the process quite a lot 20:13 <@vapier> Flameeyes: i'm not arguing that this needed a GLEP, just that it should not have been done without being on the gentoo-dev mailing list 20:14 <@Flameeyes> vapier, I can see your point in this, and I can agree on that, seeing it afterward 20:14 <@Flameeyes> I certainly wasn't expecting this much of discussion on it anyway 20:14 <@Flameeyes> still, I see the need for a min-spec for smaller changes an overkill 20:14 <@vapier> usually after arguing it out on gentoo-dev, it is generally apparent whether it needs a GLEP 20:15 <@vapier> if everyone is like "great super happy hard love it", then you do it 20:15 * Flameeyes needs to take a quick shower 20:15 <@lu_zero> vapier knowing the people there you ALWAYS need a glep 20:15 <@Flameeyes> you already knows my point so I suppose I can go afk for a few mins ;) 20:15 <@lu_zero> ok 20:15 <@lu_zero> or you could bring the laptop there 20:15 <@jokey> I'm with vapier here, sometimes small things turn out to rattle more cages you might have thought of ;) 20:16 <@dberkholz> well, you could imagine getting council approval without having a full glep 20:16 <@lu_zero> dberkholz and which are the minimum requirement for this small glep? 20:17 <@dberkholz> just post your patches and a summary, following their discussion on -dev, when the council agenda request goes out 20:18 <@lu_zero> fine for me 20:19 -!- yoswink [n=yoswink@gentoo/developer/yoswink] has joined #gentoo-council 20:20 <@jokey> more input or? 20:22 <@Flameeyes> back 20:23 <@Flameeyes> dberkholz, if we make that a feasible and accepted way, that works for me 20:23 <@dberkholz> i don't see anything prohibiting it now 20:23 <@dberkholz> people can submit anything they want to the council 20:24 <@Flameeyes> dberkholz, sure, the problem is if that will make those things "properly" submitted or not... 20:24 <@lu_zero> I'd say that would be up to su decide if we need a full glep or not 20:24 <@lu_zero> (yes I'm asking for pain) 20:24 <@vapier> i think current state is fine 20:24 <@lu_zero> s/su/us/ 20:25 <@dberkholz> exactly 20:25 <@dberkholz> we can say, either that needs a glep, or sure we'll take it like this 20:25 <@dberkholz> or, take it back to -dev, we won't decide on that 20:26 <@dberkholz> the only thing i'm a stickler about is making sure that non-glepped things have accompanying documentation 20:28 <@lu_zero> I'm fine with it 20:29 <@dberkholz> now a question of how to deal with these undiscussed global changes in the future 20:29 <@dberkholz> do we leave them, or revert them? 20:29 <@Flameeyes> I'd say decide on a case-by-case, by mail consultation with the council 20:30 <@jokey> well everything like that should go through -dev first 20:30 <@jokey> otherwise plain revert it 20:31 <@dberkholz> ok, what if we assume it will be reverted but the council can veto 20:31 <@jokey> then it also has to leave a comment on -dev 20:31 <@dberkholz> we agree that these things need to go through -dev beforehand, right? 20:32 <@jokey> right 20:32 <@lu_zero> yes 20:32 <@dberkholz> so if they don't, and we do nothing, that doesn't exactly help 20:32 <@jokey> we revert it and post (at least) a notice to -dev about it 20:33 <@Flameeyes> problem is defining what "undiscussed global changes" mean 20:33 < kingtaco|work> something that affects more than what you control 20:34 <@dberkholz> certainly things affecting every ebuild author would qualify as global 20:34 <@Flameeyes> kingtaco|work, well, there is always a project controlling software 20:34 <@vapier> Flameeyes: care to write a GLEP about the meaning of "undiscussed global changes" ? 20:34 <@Flameeyes> I'd consider a change in portage behaviour global, but portage code is under portage's devs control for instance 20:35 <@vapier> global should be pretty self evident 20:35 <@vapier> if other people outside your team are affected 20:35 <@vapier> blamo 20:35 < kingtaco|work> that's a pretty easy way to see it 20:35 <@vapier> it's the same "global" definition we've always used 20:35 <@vapier> new developers: when do you use gentoo-dev ? 20:35 < kingtaco|work> easier to define local and let global be the res 20:35 < kingtaco|work> rest 20:35 <@vapier> global issues ! 20:38 <@Flameeyes> do doc team have to pass through -dev to change the guidexml dtds for instance? 20:38 <@Flameeyes> the dtds are under doc project's control, but guidexml is not just used by doc team 20:39 -!- ZeRoX [n=zerox@nelug/developer/zer0x] has joined #gentoo-council 20:40 <@dberkholz> they should probably pass through gentoo-doc instead 20:40 <@jokey> guidexml was "offered" by doc team, so it's a related issue with them 20:41 <@dberkholz> perhaps with a pointer to the discussion on -dev if it's really significant 20:41 <@jokey> (and should be on their mailinglist as dberkholz pointed out= 20:41 * Flameeyes still thinks this is subjective a lot from one's prospective 20:43 < kingtaco|work> Flameeyes, which is why communicating when there is any question if it's global is important 20:43 < kingtaco|work> really, a quick poll in #-dev is enough to figure out if people consider a topic global 20:46 <@jokey> indeed. communication++ 20:46 * Flameeyes still isn't much revert-happy but it's not his decision 20:46 <@lu_zero> well I'd rather avoid that 20:47 <@lu_zero> still telling on -dev what you are doing isn't that problematic 20:48 <@dberkholz> all our code's in version control, it's not like reverting something makes it disappear forever. it's trivial to re-commit later after it's been discussed 20:48 <@Flameeyes> lu_zero, I think that in case like this, when skipping -dev is an overseen rather than malicious action, reverting would be too much 20:48 <@dberkholz> i think that doesn't make any difference 20:49 < kingtaco|work> dberkholz, out of all the problems we've had, revert wars have not been one. should try to keep it that way :) 20:49 <@dberkholz> well, it's no war because the buck stops with the council 20:49 <@dberkholz> you commit undiscussed global change. council reverts it. if you recommit without council approval, we kick you out. 20:51 < kingtaco|work> you don't see the problem with that? 20:51 <@dberkholz> what's the problem? 20:51 < kingtaco|work> if it needed to be reverted, then it's likely urgent enough that it cannot tolerate the latency of a council vote 20:52 < kingtaco|work> otherwise the revert is a punishment and nothing more 20:52 <@jokey> two council members can decide temporarily until next meeting 20:52 <@lu_zero> ok 20:52 <@Flameeyes> kingtaco|work, that's exactly what I meant 20:52 <@Flameeyes> I'm not against a revert _if needed_, I'm against revert as just a punishment 20:53 < kingtaco|work> it's just kind of pointless to revert if there's not a need 20:53 < kingtaco|work> it's gonna hurt peoples feelings 20:53 <@Flameeyes> hence my "case by case" idea 20:53 < kingtaco|work> flamewars will probably ensue 20:53 <@dberkholz> how is it a punishment? it's saying you can't commit things we haven't discussed, because they may be half-baked 20:54 <@dberkholz> if people commit things we haven't discussed despite that, it just encourages lack of discussion because people will keep on doing that 20:54 < kingtaco|work> that's true 20:54 < jmbsvicetto> If it's a policy violation, than qa should be the one doing the revert in the first place 20:54 < kingtaco|work> need a more active QA before that's possible 20:54 < kingtaco|work> in theory QA should be doing it though, yes 20:54 < NeddySeagoon> You have just decided the USE documentation on a case by case basis ... if it was good enough for that, why not going forward too, now the precedent has been set ? 20:55 <@dberkholz> it's grandfathered in 20:55 <@dberkholz> we can't retroactively apply new rules 20:56 <@lu_zero> ok 20:56 <@dberkholz> ok, here's what i've got 20:56 <@dberkholz> Any future global changes that aren't discussed on -dev in advance will 20:56 <@dberkholz> be reverted unless two council members vote to veto the reversion. Those 20:56 <@dberkholz> changes must be discussed on -dev and approved by the council before 20:56 <@dberkholz> recommitting. 20:57 <@dberkholz> Flameeyes: it might make you feel a little better that it would have to be a pretty bad idea if it couldn't even get 2 council members to stop it from getting reverted 20:57 < kingtaco|work> who can "revert" 20:57 <@dberkholz> i just added "by the council" 20:57 <@Flameeyes> dberkholz, I'd have preferred it the other way, but it's not me to decide, I shouldn't really vote on this issue at all 20:57 < kingtaco|work> a consensus of people who happen to be active? QA(when it's active)? anyone with a grudge? 20:58 <@Flameeyes> [the other way as in, it will be reverted _if_ two council members vote to revert] 20:58 <@dberkholz> sure you should, it's not applying to your thing =) 20:59 <@dberkholz> Flameeyes: that would make it easier to revert, since only 2 need to favor reversion instead of 2 opposing it. is that what you want? 21:00 <@Flameeyes> dberkholz, I consider the council savvy enough on the issues to decide if it's really the case to revert 21:00 <@dberkholz> it does simplify the logic, though 21:00 <@Flameeyes> on the other hand we could give an option to freeze, other than revert 21:00 <@Flameeyes> [like was done last year for the multiple version suffix - was it last year?] 21:02 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council 21:02 <@dberkholz> i think that reverting something makes it more likely to get fixed than leaving a halfway-working thing in place 21:02 <@Flameeyes> so the option would be a) revert, and ask for fleshing out before next council meeting; b) freeze, and again ask fleshing out before council meeting, otherwise the change is reverted; c) leave it go 21:03 <@dberkholz> i'm sure we're all familiar with hacky code that barely works, but never gets fixed 21:03 <@Flameeyes> dberkholz, hence why the council should then revert if there is no intention to flesh out the details 21:06 <@Flameeyes> I'd actually expect freeze (under the threat of reversal) being more effective than direct reversal 21:06 <@Flameeyes> as that makes less likely that the person involved would just be frustrated and would give up about fleshing the changes up 21:07 <@dberkholz> is it really that hard to submit a complete patch? 21:08 <@Flameeyes> no, but there can be mistakes in judgement because one change is not felt global by who made it, but it is from others, so, it might happen 21:08 <@dberkholz> (on a side note, if we used distributed scm this would be a nonissue) 21:09 <@dberkholz> Flameeyes: you think there are cases where one person absolutely feels it's non global and another person feels it's global? 21:09 <@Flameeyes> I'm certainly not saying this to get an escape route to fasttrack things that one knows should be discussed 21:09 <@Flameeyes> dberkholz, yes 21:09 <@dberkholz> if it's ambiguous, people should ask 21:09 <@dberkholz> as kingtaco|work was saying earlier 21:09 <@Flameeyes> dberkholz, problem is, one might not feel like there's the need to ask... if he knew he'd would just submit the thing to -dev :) 21:10 <@dberkholz> Flameeyes: can you cite a real instance of this? 21:10 <@lu_zero> I won't spend more time on this point... 21:10 <@lu_zero> reverting and recommitting isn't that problem 21:11 <@Flameeyes> dberkholz, well, I for one wasn't much thinking about the metadata change as a global issue, considering dtd seemed to be under doc's control 21:11 <@jokey> it isn't under docs control in any way 21:12 <@Flameeyes> jokey, beside the fact that only doc team can actually commit to that directory you mean :) 21:12 <@dberkholz> ok, i don't want to get into that 21:12 <@dberkholz> i'm going to post what i've got and we can vote on it 21:13 <@dberkholz> Any future global changes that aren't discussed on -dev in advance may reverted by the council if at least two council members vote to revert the changes. Those changes must be discussed on -dev and approved by the council before recommitting. If they're recommitted without council approval, the developer in question gets kicked out. 21:13 <@Flameeyes> what am I saying is that if it is trivial to recognize a global issue afterward, it's not that easy beforehand for some things, so I wouldn't expect a mistake never to happen; certainly I don't want that to be used as excuse for malicious forcing 21:13 * Flameeyes votes yes 21:14 <@dberkholz> i agree with myself 21:14 * jokey votes yes 21:14 <@Flameeyes> dberkholz, that's good, otherwise we should be calling an hospital ;) 21:14 <@dberkholz> and i also want to get on with this 21:16 <@amne> sounds good 21:16 <@dberkholz> alright. let's talk code of conduct 21:17 <@lu_zero> fine 21:17 <@lu_zero> anything changed from the former proposal? 21:18 <@dberkholz> musikc suggested some changes 21:18 <@dberkholz> that we should cap moderation at 2 days 21:19 <@dberkholz> no need for council approval for longer periods because they won't happen, and it'll just get handed off the devrel 21:20 < fmccor> What about user-on-user? 21:20 <@dberkholz> good question 21:20 <@dberkholz> the only action we can take then is moderating/banning then 21:20 <@dberkholz> suppose it should go to userrel 21:21 <@dberkholz> she also emphasized that we should focus on #gentoo-dev and the -dev list, because the other places (forums, other irc etc0 already have mods in place 21:22 <@jokey> ack on the last one 21:22 <@dberkholz> and perhaps more than focus, actually say that this is just dev mods for those 2 places and nothing else 21:23 <@lu_zero> so far fine for me 21:23 <@dberkholz> i like that last idea 21:23 <@jokey> same here, that way the impact is also predictable 21:24 <@dberkholz> and if CoC standards turn out to be a problem in specific places, the council could directly work with those people 21:24 < NeddySeagoon> The CoC still applies other places, where its enforced by the existing moderation groups, so no issue there 21:25 <@dberkholz> so anywhere but gentoo-dev list and irc would have no bearing on this proposal 21:25 <@lu_zero> and if another place appears, well we'll extend later 21:25 < Philantrop> What about Bugzilla when it's dev vs. dev? 21:26 < fmccor> Right now, devrel does that when called in. 21:26 <@dberkholz> devrel's been handling that in the past, right 21:26 < fmccor> Generally we (I at least) have to be called, otherwise I won't see it. 21:27 <@dberkholz> right. i don't think anybody, or any group of people, can expect to read all the bug traffic. 21:29 < kingtaco|work> I bet jakub does 21:29 <@dberkholz> i will change the proposal to just cover gentoo-dev stuff, make a few other refinements, and post to the -council list again 21:30 <@dberkholz> since it seems like people generally like that idea 21:30 <@lu_zero> =) 21:30 < NeddySeagoon> dberkholz, #gentoo-dev is not controllable while everyone has ops 21:30 < kingtaco|work> wrong 21:31 < kingtaco|work> devrel has the ability to perm remove ops 21:31 <@dberkholz> guess they'll have to get deopped temporarily, then 21:31 < NeddySeagoon> kingtaco|work, true butthat takes days 21:31 < kingtaco|work> the peons can deop each other all they want, devrel has the ability to do it and make it stick 21:31 < kingtaco|work> NeddySeagoon, something to take up with them I suppose 21:32 < kingtaco|work> there seems to be a lot of things in devrel that people want to go faster 21:32 <@jokey> from what we heard on freenode, they have some admin user for the channel and a handful of people know the password to it 21:32 <@jokey> maybe we can do the same 21:32 < kingtaco|work> not needed 21:32 <@dberkholz> anyone with a high enough chanserv access level can change anyone lower's levels 21:32 <@jokey> they being ubuntu and freebsd 21:32 < kingtaco|work> a person needs access level of 30 21:33 < kingtaco|work> to control #-dev 21:33 < kingtaco|work> and 40 to control those who control #-dev 21:33 <@dberkholz> and infinity to control the universe! bwahahaha 21:33 < NeddySeagoon> kingtaco|work, there are two different sorts of coc enforement. An instant cooling off period and longer term for repeat offenders. How do you do the instant cooling off in #gentoo-dev 21:34 < kingtaco|work> NeddySeagoon, I don't have the answer, just telling you what's possible with the current setup 21:34 <@jokey> that brings up the question... who enforces CoC? 21:34 <@Flameeyes> dberkholz, I think the level is capped at 99 when you insert the master password ;) 21:34 <@dberkholz> the moderators of whatever location 21:34 < NeddySeagoon> kingtaco|work, I don't have the answer but being a proctor taught me some of the questions 21:35 -!- ryker [n=none@a01-03c-084.calumet.purdue.edu] has quit [] 21:35 <@dberkholz> you could just ban folks for a while, have to remember to unban later though. 21:36 <@Flameeyes> people with op can auto-unban themselves 21:36 <@dberkholz> yes, you'd clearly have to change the levels 21:36 < jmbsvicetto> dberkholz: on #-dev with the current setup, you'll have to give moderators an access level of 30 21:36 <@dberkholz> i guess i'd prefer to just -op -voice and let people idle in there, so they don't miss anything 21:36 <@Flameeyes> dberkholz, quietban 21:36 <@dberkholz> as opposed to actually banning 21:37 <@jokey> mode +q afaik 21:37 <@dberkholz> Flameeyes: sure, bout the same effect in #-dev 21:37 < kingtaco|work> except the friend of the banned will unban/unmute/whatever, prompting that person to be banned/muted, prompting another person ......... 21:37 <@dberkholz> yep, won't it be fun? 21:37 < kingtaco|work> it's never one person against the world 21:37 < kingtaco|work> yes 21:38 < kingtaco|work> that's why it's ineffective 21:38 <@dberkholz> that's a bit of a stretch 21:38 < kingtaco|work> to the point that it's actually negative IMO 21:38 <@Flameeyes> let's all devs have voice and not op? still allowing them to give voice to others upon request? 21:38 <@dberkholz> that's just about lack of respect for the council and CoC, if people do that 21:38 < kingtaco|work> instead of one problem person, you now have the group that sided with said person as the problem 21:38 <@dberkholz> and for gentoo as a whole 21:39 <@Flameeyes> after all the most used op feature in #gentoo-dev is giving voice to contributors 21:39 < NeddySeagoon> kingtaco|work, I think you have to take ops away from everyone except the chan managers and coc enforcers 21:39 < kingtaco|work> well, I assert that there isn't much respect for council, CoC or gentoo around here 21:39 < Philantrop> Do we really have such big of a problem in #-dev that we need to make such a fuss about it? :) 21:39 <@dberkholz> if a whole group of people chooses to get modded, who cares 21:39 <@dberkholz> good for them 21:40 < NeddySeagoon> Philantrop, there is a perceived need for coc enforcement 21:40 <@dberkholz> that doesn't mean we should just let things be a free-for-all with no community standards 21:40 < kingtaco|work> not suggesting that 21:40 < kingtaco|work> I'm suggesting the proposed solution to the perceived problem is actually more negative that the problem due to the snowball effect 21:41 <@dberkholz> i'm suggesting that your suggestion is not a problem if people know in advance what will happen =) 21:42 < kingtaco|work> I respectfully disagree 21:42 < kingtaco|work> but I've made my point :) 21:43 <@dberkholz> and if this snowball effect you suggest, does happen, i also suggest that it's not a bad thing to mod everyone involved because it makes a point 21:43 <@dberkholz> multiple people breaking a rule don't get away with it any more than just one 21:43 < NeddySeagoon> dberkholz, until you get modded 21:43 <@dberkholz> i do occasionally do other things besides sit in front of the computer =) 21:44 < kingtaco|work> I recommend you find a solution that minimizes the potential for the snowball effect 21:44 < kingtaco|work> if it happens so be it 21:44 < NeddySeagoon> I was meaning in the process of quieting an unruly group 21:44 <@dberkholz> but if i do something wrong, i don't expect to get away with it any more than anyone else 21:45 < NeddySeagoon> if you don't change the access list, /cycle will give users there privs back 21:46 <@lu_zero> hm 21:46 < NeddySeagoon> anyway, we will not get an nswer here 21:46 <@dberkholz> ok. does anyone have any new points to make about this? 21:46 <@dberkholz> emphasis on new 21:47 < kingtaco|work> not I 21:48 <@dberkholz> ok 21:49 <@dberkholz> in closing, i'll post an updated draft to the -council list for discussion 21:49 <@dberkholz> seems like we're getting somewhere by narrowing the scope a bit 21:49 < jmbsvicetto> I would just recall that in the case of the mls you need to make sure the tools exist before you ask anyone to moderate them 21:49 < NeddySeagoon> dberkholz, the scope is not narrowed - the coc is enforced in other areas by existing groups 21:49 < kingtaco|work> infra hasn't removed any of the tools 21:50 < kingtaco|work> that said, we'll probably be pretty latent in making new ones, so I suggest you really try to use what's existing 21:50 <@dberkholz> NeddySeagoon: the scope of the changes, anyhow. the other areas were already happening 21:50 < NeddySeagoon> jmbsvicetto, they do but nobody gets gentoo-dev ml messages sent for moderation 21:51 <@dberkholz> ok, let's wrap this topic up and move to the open floow 21:51 <@dberkholz> floor, too 21:51 <@jokey> ack 21:51 <@dberkholz> Philantrop had one particular issue to raise 21:52 <@dberkholz> which PMS is authoritative? 21:52 < kingtaco|work> how is there any question to that? 21:52 < Philantrop> Personally, I'd prefer the one that is actually being worked on - regardless of where it's hosted. :-) 21:53 <@dberkholz> kingtaco|work: well, there's one that's actually been getting changes, and one that hasn't 21:53 < Philantrop> kingtaco|work: The one on our infrastructure doesn't even have EAPI1 docs. 21:53 <@dberkholz> you mentioned something about the pms repo earlier, so maybe you have a clue what's going on 21:53 < kingtaco|work> I don't have the details, but here's the general gist 21:54 < kingtaco|work> we're going to treat PMS the same as ubers baselayout repo 21:54 <@jokey> except that ours is not being worked on but the external hosted one is 21:54 < kingtaco|work> in the past, the only hold up on moving PMS to gentoo is there were a couple external contributers that were offended by the thought of having to pass their commits through a dev 21:55 < kingtaco|work> this removes that 21:55 < kingtaco|work> as for which one gentoo follows, it's kind of foolish that we would follow an external spec for something that gentoo created 21:55 < Philantrop> kingtaco|work: I apologize if I ask something that has been covered but how do we treat Uber's repo? :) 21:56 < kingtaco|work> regardless of what external projects do 21:56 < kingtaco|work> Philantrop, via git 21:56 < Philantrop> kingtaco|work: Ah, so we pull regularly? 21:56 < kingtaco|work> I don't know the git specific terms, but the repo is hosted by gentoo 21:56 < Philantrop> kingtaco|work: Yes, that's the status quo. :) 21:57 <@dberkholz> well, it seems more like uber etc will be able to push to our repo, actually 21:57 <@dberkholz> we're going to be able to allow pushes by external contributors 21:57 < kingtaco|work> we don't replicate someone elses repo, we're hosting it 21:57 <@jokey> once we get the new overlays box in place 21:57 <@dberkholz> kingtaco|work: fyi, a pull would mean we had a designated person merging in external changes from other repos 21:58 < kingtaco|work> dberkholz, ok, it's certainly not that 21:58 < Philantrop> kingtaco|work: a) That's semantics. b) The "external contributors" you're probably referring to don't want to push to our repository. 21:59 < kingtaco|work> Philantrop, I only know of one person who had the problem, and frankly, his problems are his own 21:59 < kingtaco|work> gentoo does not need to bend itself to accomodate him 22:00 < kingtaco|work> as far as I care, any perceived responsibility ends when we make the service available for him to use 22:00 < kingtaco|work> we certainly can't force him to use it 22:00 < Philantrop> kingtaco|work: I agree with the latter. Nevertheless, from what I was told by several people he's not the only one. And we, as in Gentoo, don't seem to work on PMS currently. 22:01 < kingtaco|work> I don't doubt there are others, but I can't address them if I don't know what the specific issue is 22:01 <@jokey> main issue is, only the guy who did the initial svn conversion can continue syncing up 22:01 < kingtaco|work> and again, gentoo is not held hostage by external contributers 22:03 <@jokey> right 22:03 < Philantrop> kingtaco|work: No, but there's a current, functional SVN repository and an outdated one on our infrastructure. There's no actual work on our repository. There is on "their's". Will it kill us to choose theirs? :-) 22:03 < kingtaco|work> Philantrop, yes it would 22:03 < kingtaco|work> it's very clear, gentoo sets it's own standards 22:04 < Philantrop> kingtaco|work: Ah, I see. It will kill ego's. :-) 22:04 < kingtaco|work> we can't prevent others from trying to set or influence them, but at the end of the day gentoo is only responsible to itself 22:04 < kingtaco|work> ugh, I'm done 22:04 < Philantrop> kingtaco|work: Same here. 22:05 <@dberkholz> Philantrop: it's not really about egos as much as control over the specification of our own package format 22:05 <@vapier> we already had this discussion 22:05 <@dberkholz> it's fun to do it every week though, don't you think? 22:06 < kingtaco|work> it's a waste of time 22:06 < Philantrop> dberkholz: I absolutely agree in general. But we don't even have an official documentation for EAPI1. 22:06 < kingtaco|work> gentoo has gone more than half way to accomodate external people 22:06 < kingtaco|work> screw them if they still don't want to play nice 22:06 <@dberkholz> alright, we're not making any progress here 22:06 < kingtaco|work> I'll have none of it 22:06 <@dberkholz> so you guys can continue the discussion after the meeting if you want 22:06 * Philantrop considers the place where the actual *work* takes place as authoritative until something significant happens in our repo. 22:06 <@dberkholz> any other topics for the open floor? 22:07 <@lu_zero> I guess not 22:08 <@dberkholz> ok, meeting's over. thanks for playing.