Add 13 December meeting.

1 files changed, 369 insertions, 0 deletions

diff --git a/meeting-logs/20071213.txt b/meeting-logs/20071213.txt
new file mode 100644
index 0000000..8a78510
--- /dev/null
+++ b/meeting-logs/20071213.txt
@@ -0,0 +1,369 @@
+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.