path: root/meeting-logs/20071213.txt

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.