[16:02] --- kingtaco|work sets modes [#gentoo-council +m] [16:02] lets get this shit started [16:02] <-- amne has quit (Remote closed the connection) [16:02] roll call [16:02] I'm 'ere [16:02] Kugelfang, robbat2, SpanKY, Uber, wolf31o2|work [16:02] hi [16:03] --> amne (n=amne@85-124-176-198.dynamic.xdsl-line.inode.at) has joined #gentoo-council [16:03] .... [16:04] I don't have time to idle [16:04] ? [16:04] pon [16:04] g [16:04] anyone have any agenda? [16:04] me neither [16:04] i dont one's been posted, but i'd like to know what's up with pms repo on gentoo.org [16:04] and we should decide about sept [16:04] <-- desultory has quit (Client Quit) [16:05] --> desultory (n=dean@gentoo/developer/desultory) has joined #gentoo-council [16:05] whats up with sept? [16:05] maybe it's on one of the servers that was taken down recently [16:05] um, we don't have any servers by that name [16:05] --> hparker (n=hparker@gentoo/developer/hparker) has joined #gentoo-council [16:05] as in the month [16:05] toolbox [16:06] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council [16:06] this is supposed to be our last meeting, new council in sept [16:06] however due to delays, voting doesnt end soon enough [16:06] fox2mike announced the vote this morning [16:06] I suppose a meeting is skipped [16:06] i'd make the statement: sept is a floating month ... if new council isnt voted in soon enough, existing council handles sept [16:07] sounds fair enough [16:07] but regardless, aug will continue to be the official last month [16:07] yeah, we should always have a council [16:07] so we dont have to deal with an ugly sliding window of "1 year" [16:07] sure [16:07] my bad on the pms repo, but the PMS guys haven't done much lately either - http://pastebin.ca/660160 [16:07] there was still flak from them on why to have it moved anyway [16:07] more on that in a bit [16:08] one sec [16:08] we agree on the sept issue ? [16:08] --> astinus (n=alex@gentoo/developer/astinus) has joined #gentoo-council [16:08] * Uber votes yes [16:08] sound off like you have a pair [16:08] vote: old council will stay past their date in the event a new council hasn't been elected [16:08] yes [16:08] yes [16:08] yes [16:08] yes [16:08] yes [16:08] * kingtaco|work prods Uber [16:09] i'll tweak the glep/docs/whatever and make announce later [16:09] WFM [16:09] next [16:09] pms stuff [16:09] robbat2, vapier ? [16:09] i'm not going to hound pms until gentoo.org repo is ready [16:09] and i have yet to hear "it is" from robbat2 [16:10] robbat2, ? [16:10] there's give and take that they didn't want to give up being able to commit directly, that's also what other projects are saying that want external folk working on things (overlays most notably) [16:10] i still haven't gotten the ACL stuff safe to my satisfaction either [16:10] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council [16:10] that's why I haven't called it 'ready' [16:10] --- kingtaco|work sets modes [#gentoo-council +o jaervosz] [16:11] it's as up to date as the upstream SVN [16:11] which isn't moving fast at all [16:11] delay yet another month? [16:12] i'd like to ask [16:12] here's the part i want: when you say the repo is in a usable state with ACL's able to grant/revoke write access [16:12] when that is ready, we move it and we're done [16:13] i see some repos moving away from Gentoo infra already because people want external contributors, and infra has historically said we won't give it to them [16:13] I don't see that changing anytime soon [16:13] not on the cvs/svn server [16:13] from a security point of view [16:13] it's not safe to do with CVS and SVN [16:13] maybe someplace else like overlays or soc or sunrise [16:13] but is doable safely with Git [16:13] witness repo.or.cz [16:13] which is where some of the gentoo repos have moved [16:14] they can stay IMO [16:14] infra is taxed enough as it is [16:14] we don't need to be supporting every single rcs [16:14] that begs the question why PMS can't... (playing advocatus diaboli) [16:14] if there were a gentoo git server, it'd be a non-issue [16:15] vapier, read my statement that infra is over taxed [16:15] and before you start the bring more people on, we just did [16:15] if I were less busy i'd have the ACLs done already [16:15] everyone is taxed [16:15] that's the nature of open source [16:16] so the better question, continuing Kugelfan3's point - why force PMS to move if we are letting others stay out there? [16:16] it's certainly less load on infra if they stay out [16:16] so ciaranm has commit access I thought [16:16] because they are working on overlays and shit like that, not core policy [16:16] i dont believe in something that Gentoo relies critically on can live outside of Gentoo [16:17] I tend to agree... something like the specification that defines what is a Gentoo package manager should live within Gentoo [16:17] * Uber agrees also [16:17] after all, the package management system is likely the main defining point of Gentoo [16:17] it's a document, we don't rely on it, you can break it, it won't break anything in systems [16:17] i think you need to review your definition of "rely" [16:18] robbat2: it's like hosting our mission statement on windows servers [16:18] if the document is incorrect and a package manager is released following the incorrect spec, you *can* break boxes [16:18] s/can/will [16:19] the pms doc is a guarantee ... if you use a pm that follows the pms, then things in the tree should work [16:19] exactly [16:19] if the overlays weren't so overloaded, we could just trivially move PMS's SVN there [16:19] that said, do we(gentoo) need a pms or is it more for the external pm [16:20] looking at who contributes to it, it's mainly the paludis group [16:20] kingtaco|work: Gentoo has no need for a PMS if we're only supporting portage... it was written pretty much exclusively to allow external package managers to be on the same page as portage [16:20] which makes me wonder, does gentoo define is specs by what's in the tree [16:20] Jokey points out that the finnish translations already use the overlays box in the same fashion that I suggest for PMS [16:20] so there is certainly precedent [16:20] and it works [16:20] it's possible that any PMS is of primary use for external projects and perhaps we don't need to involve ourselves [16:21] i see the goal of PMS as allowing external PMs to be supported in Gentoo [16:21] because they do the same thing as Portage [16:21] has anyone ever thought to ask if Gentoo even cares to support external package managers? [16:21] I have no desire to support anything other than what gentoo calls official [16:21] <-- jaervosz has quit (Read error: 104 (Connection reset by peer)) [16:22] we have some Gentoo users who do care [16:22] I also have no desire to verify that an external manager is indeed PMS compliant [16:23] Uber: users don't have to actually do the support, so I'm not sure that make s a bit of difference... after all, users can do whatever they want to their systems... doesn't mean we have to support it in any way [16:23] I'd rather let the portage devs dictate what EAPI does what [16:23] afaik portage devs do want PMS [16:23] but i might be wrong [16:23] if an external manager wants to follow what we do fine. if they don't thats fine too. [16:24] do they really want it? or do they just want it to shut up the external guys? (I'm honestly asking, I have no clue) [16:24] I suspect the latter [16:24] <-- test has quit (Remote closed the connection) [16:25] kingtaco|work: that is what you suspect... why don't you ask them? [16:25] like zmedico [16:25] wolf31o2|work: I don't see it as any different compared to say supporting a another OS inside of portage [16:25] --- kingtaco|work sets modes [#gentoo-council +v zmedico] [16:25] zmedico, ping [16:25] Uber: I don't get your meaning [16:26] pong [16:26] Uber: in that case, there are developers actively working on it because they care about it [16:26] wolf31o2|work: do you expect package owners to fix freebsd bugs with their packages or the freebsd team? [16:26] Uber: that has nothing to do with an external project, so again, I don't get the bearing on this conversation [16:27] zmedico, regarding PMS, would the portage team rather develop portage and define EAPI bumps along the way or does the team feel it's important to go the PMS route? [16:28] wolf31o2|work: no, but it has everything todo with package support which is your bone of contention [16:28] the gentoo/freebsd team *is* a gentoo project, not external... as for who I would expect to fix the packages... both... package maintainers should be writing ebuilds in a portable manner and the alt arch guys should be pointing out issues as they see them and either fixing them or the maintainer fixing them, depending on the severity and extent of the issue at hand... but again, that has nothing to do with external projects [16:28] ok... that's not what I'm saying, at all [16:28] but I really don't care to continue trying to state my point repeatedly... so I'll just say "sure" and we can move on [16:29] portable isnt quite the word ... we've got an informal standard of things that are/are not OK [16:29] which is fluid and changes as agreed on gentoo-dev mailing list [16:29] * wolf31o2|work hands the pedantic hat to vapier [16:29] I mean things like... using "cp -a" [16:29] gimme my hat back bitch [16:29] kingtaco|work: EAPI bumps should be based on input from the general ebuild developer community I think, since the the purpose of EAPI bumps is to give them features that they want. [16:29] zmedico, thanks [16:29] OK: gnu make NOT: crappy POSIX make [16:30] sure [16:30] and if I start using "cp -a" in ebuilds, I'd expect the freebsd guys to come give me a good hard ass kicking [16:31] yes you would :P [16:31] ok, so I ask again, why does gentoo itself care about PMS [16:31] cp -RPp [16:31] but *only* because we agreed on the ass kicking ahead of time on the gentoo-dev mailing list [16:31] * Uber nods [16:31] we care about it only to define what features are supported in a given EAPI version so it can be used by ebuilds devs [16:31] no, the discussion on -dev ml defines eapi bumps [16:32] which brings us back to do we just merge the doc into portage svn or overlay svn and be done [16:32] when we agreed on project originally, we gave it to the QA team to maintain [16:32] or just ignore it, and start working on eapi1 [16:32] which has been needed for quite a while [16:33] vapier, would seem they've dropped the ball [16:33] it's more specific features that are needed than just an "eapi1" [16:33] I agree... it's been a year and we still don't have a completed spec... [16:34] eh, i would look at it more along the lines of is the QA team even appropriate [16:34] in it's current form, I'd say no [16:34] having it split between teams seems to have just added overhead [16:35] <-- Ingmar^ has quit (Read error: 60 (Operation timed out)) [16:35] I would say no... [16:35] if the route we're going is that we dont add crazy things to EAPI/PMS unless we cover it in gentoo-dev, then having it be with the current package manager would lessen that maintenance [16:36] ok... do new features require council buy-in? [16:36] i think originally the idea was that we needed QA team to watch over it as we had a much more fluid "standard" [16:36] well, it was the qa team that was pretty much asking for it, too [16:36] but the portage team has reeled themselves in wrt keeping things stable [16:36] true [16:36] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council [16:36] i dont think stating council buy in is appropriate [16:37] handle it like anything else ... let it sort itself out and if it doesnt, then we stick a foot in it [16:37] the figurative "Council Boot" if you will [16:38] ok... reason I am asking is it would determine where pms would best fit... being a global technical document, the best place for it really is the council... in fact, all of our technical specifications really belong under the council, being the council is the primary technical decision-making body... [16:38] which would still work with the "council boot" [16:39] we take a more fallback guidance roll rather than being on the fore-front [16:39] is there a license on the pms stuff? [16:39] <-- jaervosz has quit (Read error: 104 (Connection reset by peer)) [16:39] it's all create commons [16:39] so yes, we can just take it [16:39] iirc it's ccsa, but I don't remember exactly [16:39] so just take it and be done [16:40] the cryers are going to cry no matter what we do [16:40] the community decides, council steps in when community cant sort itself out [16:40] people will leave [16:40] shit happens [16:40] the community hasn't said anything on it in months [16:40] i think anyone who would leave over pms has already left ;) [16:40] we're in limbo [16:40] lets get out and be done with it [16:40] nobody has brought a new GLEP up in many months [16:40] vapier: no, i haven't yet [16:40] vapier: but i will [16:41] so we pull it in house, finalize it, publish it as a finished spec, then move onto the next thing... [16:41] whatever floats your boat [16:41] I don't understand why we have to accomodate any external party [16:41] well, no matter what, the finished version of the spec needs to be on our infra somewhere... even if the repo behind it isn't... I just dont' see a point in keeping them separate [16:41] we might choose to, but being forced like this is silly [16:42] we aren't forced to [16:42] if we fork it to inhouse, will the inhouse fork still have enough momentum? [16:42] we can pull the repo right now [16:42] then why are we doing all this git shit? [16:42] robbat2: what momentum? [16:42] heh [16:42] touche [16:42] yeah, what momentum [16:42] there is no fork, there is only what represents the tree [16:43] well, i would imagine there would be some momentum if that happens [16:43] cue lots of posts to -dev by the usual suspects [16:43] Gentoo is open sourced, people can do whatever they like with the code [16:44] (next agenda item: ML review, requested by tomk) [16:44] right... so we pull it in and the naysayers be damned? [16:45] it isnt like where we'd be putting it would damn people [16:45] I mean, we already know that any decision (including the lack of one) will cause a flame war [16:45] i would say yes to bring it under our full control at lesat [16:45] so let's just do what we think is best and deal with it [16:45] so move it to overlays, just like the .fi translations? [16:45] Kugelfang, spb, whoever can still commit all they like [16:45] robbat2: how far away is the SoC box? [16:45] wolf31o2|work, ask kingtaco|work [16:46] (I'd prefer not abuse overlays if we don't have to) [16:46] kingtaco|laptop: ^^ [16:47] it's been ready [16:47] gimme a svn dump and it's a command away [16:47] vote: move PMS as-is SVN to SoC/Overlays/svn.g.o [16:47] user management is vanilla so that'll suck [16:47] but it's doable [16:48] what is the SoC box ? [16:48] a box meant for hosting SoC projects and the like [16:48] the closest thing we've got to allowing external people repo access [16:49] vapier: it is a new box that is half-dev/half-infra that will host repos allowing for non-gentoo contributors... for the SoC projects but also usable for this sort of thing [16:49] sorta like sunrise [16:49] does svn http:// [16:49] my vote: yes [16:49] ssh currently [16:50] hold on a sec [16:50] on that vote [16:50] vote for it to go to a specific place, not a "throw the problem at infra" [16:50] we've already thrown it at infra [16:50] why? the council doesn't care what specific box it resides on... that's infra's job... all we care about is if it is on our infra or not [16:50] * vapier looks at robbat2 [16:51] why? [16:51] do you really want the council telling you how to run your infra? [16:51] because infra doesn't want to choose acls for it [16:51] so maybe reword that [16:52] i recall infra getting angry last time we told them how to run infra [16:52] why does it need acls? any dev can commit to the tree, why not pms? [16:52] what about external people? [16:52] that's the problem [16:52] uhh... wouldn't the acls be per-repo anyway? [16:52] ok, you're missing the point [16:52] apparently [16:53] only current gentoo developers and staff have access to the cvs/svn repos [16:53] that will not change [16:53] correct... on our main svn/cvs box [16:53] that would be the default place we would put something like this [16:53] there is an open unanswered question about external contributors [16:53] answer that and infra will work the magic [16:53] grok? [16:53] then ask that question rather than beating around the bush... :P [16:53] yep [16:54] so... do we care about external contributors being able to directly commit at this point? [16:54] the way the vote was worded forced that question onto infra [16:54] hence my objection [16:54] i care for them not to directly [16:54] I don't see there being enough activity to justify it anymore... so I would say that we are not at the mercy of external contributors [16:55] so the vote really is: allow direct external contributors to spec repo [16:55] and if you are skilled enough to contrib to the PMS then you should by default be a Gentoo dev anyway [16:55] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council [16:55] Uber, careful with that, re ciaranm [16:55] Uber: that's untrue and PMS is a prime example [16:55] ex-devs can be skilled enough, too [16:55] ;] [16:56] Uber, technical skill alone does not make a gentoo dev [16:56] yes, but isn't that the point - ex dev means not a gentoo developer. Hence as they're not a gentoo developer then they have less power to affect gentoo development [16:56] how about this then: infra gets it moved to a Gentoo box asap, and shuffles it to soc/overlays later if there is a large demand for direct external commits [16:57] I'd agree to that [16:58] ok [16:58] <-- jaervosz has quit (Read error: 104 (Connection reset by peer)) [16:58] --> Ingmar^ (n=ingmar@83.101.12.130) has joined #gentoo-council [16:58] vote: fork current external pms repo into svn.gentoo.org and follow up if/when external contributors whine [16:59] no [16:59] what is the follow up [16:59] what i've heard in the past was "no" [17:00] the follow up is someone deciding if/when to move it to a place where external people can commit directly [17:00] Kugelfan3, do you want it straight to somewhere that externals can commit directly? [17:01] or just don't want it to move [17:01] does it matter? [17:01] it's a yes or no vote [17:01] ;] [17:01] heh [17:01] i'm wondering why he said no [17:01] robbat2: don't move.... [17:01] my vote: yes [17:01] that doesnt answer his question [17:02] y'all can vote any time... [17:02] yes [17:02] don't get shy now [17:02] yes [17:02] vapier, ? [17:03] i'm for it ... unify current + portage access to the repo [17:03] kingtaco|laptop, jaervosz? [17:04] my vote is yes [17:04] jaervosz is a slacker today [17:04] and jaervosz seems to have timed out again [17:04] ok, so it's passed and done [17:04] any other topics? [17:04] infra needs to get an svndump from the existing site [17:05] and then just put it online [17:05] robbat2, I thought you had one? [17:05] ask spb for it [17:05] kingtaco|work, I made my git clone via a pull [17:05] mailing lists is next [17:05] tomk wanted to know abouts lists [17:05] gentoo-dev-announce exists [17:05] for cross-posting [17:06] there is a hiccup [17:06] if you send the message only to gentoo-dev-announce, the auto cross-post fails [17:06] I don't think it necessary to vote on moderating -dev list. -project and -dev-announce seem to have resolved everything [17:06] if you put both addresses in to/cc, then the manual copy AND the auto-cross-post get to -dev [17:06] kingtaco|work: true enough - -dev is running smoothly along :) [17:06] why is dev-announce auto-forwarding anyway? [17:06] it makes it *so* much less useful that way [17:07] because people asked for it [17:07] so devs can sub to only dev-announce [17:07] or only -dev [17:07] and noone misses out on announcements [17:07] --> windzor (n=windzor@82.143.229.102) has joined #gentoo-council [17:07] but it makes it completely useless for other lists [17:07] there is some training that has to be done there [17:07] tell them just to sub? [17:07] to dev-announce or both [17:07] yeah, just auto-subscribe all devs or tell em to [17:07] I think it would be easier to just sub all devs to core and announce [17:07] right [17:08] let them decide if they want to sub to projects and dev themselves [17:08] that works [17:08] so, for example, I can send a mail to dev-announce announcing something on the releng list [17:08] still have to train people to send to the right list though [17:08] that's fine... brow beating works wonders for that sort of thing [17:08] =] [17:08] ok, so i'll go and turn off auto-forwarding and sub alls devs to dev-announce [17:09] also need to make devrel aware of the changes so they can adjust recruiters procedures [17:09] i think that part is scripted, so just adjust the script [17:09] cool... I'm going to research if it is possible to allow for a default reply-to that can be overridden... so I can set reply-to tp gentoo-releng on my releng announcements [17:09] =] [17:09] um, it wasn't when I left [17:09] we had to go to the mlmmj interface for -core [17:10] who's a recruiter in here? [17:10] it still isn't, according to phreak when I asked about adding a gwn email to their recruitment scripts [17:10] --- kingtaco|work sets modes [#gentoo-council +v Betelgeuse] [17:10] Betelgeuse, you here? [17:10] the unsub portion is definetly scripted [17:10] but not the sub [17:11] what lists? -core, -dev-announce? i'll do a script right now [17:11] ok, do we need to vote on this? [17:11] i don't think so [17:11] nor I [17:12] if it's part of the recruitment process, just let em decide [17:12] auto subscribe to all the lists that devs are *supposed* to be one [17:12] if they dont want to be on them, they can unsub [17:12] WFM [17:12] yeah, I don't think it needs a vote...w e all seem to be in agreement [17:12] any thing else on this topic? [17:12] no? [17:12] ok [17:13] umm, i think there was something on 4chan.org/b [17:13] anyone have anything else? [17:13] hahaahah [17:13] anonymous++ [17:13] kingtaco|laptop: you post logs/summary for last meeting [17:13] kingtaco|work: yes [17:13] yes, we're going to pull a feed from 4chan to the front page, right? [17:13] kingtaco|work: what do you need? [17:13] cause if you didnt, you need to [17:13] vapier, I don't log anymore [17:13] if you don't see my base nick I don't have a log [17:13] i was a slacker at that meeting [17:14] Betelgeuse, how new devs are sub'd to -core [17:14] i'll give you my logs, and you can summarize [17:14] so someone needs the logs for it [17:14] kingtaco|work: recruiters add them [17:14] kingtaco|work: via a web interface [17:14] Betelgeuse, care for a one-shot script? [17:14] Betelgeuse, k, that's what we assumed, wanted to make sure it didn't change [17:14] robbat2: just e-mail them to me please [17:14] robbat2: script? [17:14] robbat2: For what? [17:14] ok, any other topics? [17:15] we really gotta stay focused [17:15] people got work to do [17:15] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council [17:15] last chance.... [17:15] i think we're done [17:15] <-- igli (n=igli@unaffiliated/igli) has left #gentoo-council [17:15] --- kingtaco|work sets modes [#gentoo-council -m] [17:15] open floor [17:15] robbat2: actually i see 20070712 posted, so someone did it [17:15] flame away [17:16] heh, I apparently missed the council meeting [17:16] robbat2: actually it looks like *you* did it [17:16] go andrew! [17:16] I just switched to this window [17:16] Suggestion for next meeting --- why not postpone it until after election, like this one was postponed for LWE? [17:16] Now, you've been talking about moving PMS for many months now. What is the technical reason for such a move? [17:16] did I miss anything interesting? :P [17:16] you missed the no-pants-vote [17:16] Kugelfan3: while you're here, care to say who's in charge of eselect while you and spb aren't around? [17:17] vapier, well do you have logs of this one? [17:17] vapier: quick question....once pms is on gentoo infra when will it be officially stamped as "accepted"? [17:17] robbat2: yes [17:17] Similar situation --- this one was moved because council could not be here last week. Move next for same reason. [17:17] genone: ask pioto [17:17] dostrow: dont see why not once we get the few things missing merged [17:17] fmccor: makes sense [17:18] vapier, By accident, that happens on occasion. :) [17:18] fmccor: the council isn't only the council for the meetings... they're the council the entire time... one way or another, we have to stay on as council until the election is done [17:18] whether we end up at the next meeting or not [17:18] Sure. I was only talking of the meeting date. [17:19] both good points [17:19] So that next council would have their full 12 meetings. [17:19]