From 33cd7569dd090fad06e9d9e73bdc8f889a3dd0b0 Mon Sep 17 00:00:00 2001 From: Donnie Berkholz Date: Thu, 13 Dec 2007 23:01:39 +0000 Subject: Add 13 December meeting. --- meeting-logs/20071213.txt | 369 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 369 insertions(+) create mode 100644 meeting-logs/20071213.txt (limited to 'meeting-logs/20071213.txt') 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. -- cgit v1.2.3-65-gdbad