20:00 * dertobi123 yawns 20:00 <@dberkholz> yep, bout that time. 20:00 <@dberkholz> council & secretary, please speak up 20:01 <@lu_zero> '/ 20:01 < mama> tanderson said he's not gonna be here. 20:01 <@leio_> the secretary told to be away 20:01 <@leio_> apr 09 17:24:24 I will not be making it to today's meeting :(. My mom needs to pick up my brother for good friday break and the pickup time is 2000 :( 20:01 <@leio_> apr 09 17:24:57 I'll still have my irc client on to make up a summary though, so no worries there 20:01 <@lu_zero> pity 20:01 <@dberkholz> alrighty 20:01 <@dev-zero> I'm here 20:02 -!- filko [i=filko@unaffiliated/filko] has joined #gentoo-council 20:02 <@dberkholz> Betelgeuse, Cardoe: ping 20:03 <@dberkholz> ok, let's start 20:04 <@dberkholz> i put this idea of solar's at the top of the agenda because i think we can manage to avoid going into long extended arguments about it 20:04 <@dberkholz> the basic idea is to move keywording to a package.keywords file or something along those lines 20:05 <@dberkholz> reduce rsync overhead, constant redigesting of whole packages for a change to keywording, etc 20:05 <@dberkholz> downsides is that you can get conflicts 20:05 <@dberkholz> anyone got thoughts about this? 20:05 <@dev-zero> conflicts? 20:05 <@dberkholz> if keywords for all packages are in the same file, it will change very frequently 20:06 <@dertobi123> i don't get what to discuss on this topic for now, there isn't even some kind of proposal 20:06 < solar> back. 20:06 <@dertobi123> if solar needs an "ok" to draft some proposal ... here's my "ok" 20:06 <@leio_> I think it should be actually written down by someone. Abstract, problems that it solves, plan of implementation 20:06 <@dberkholz> so you might get people changing an outdated file and committing it. overwriting someone else's changes or producing a cvs conflict 20:07 < solar> dertobi123: there is no proposal. You guys are the council. I'm asking you to also put some thought into it 20:07 <@dev-zero> well, I dislike the idea for various reasons 20:07 <@leio_> make it nice, don't just try to do it with current mechanisms available if better methods could be implemented, etc 20:07 <@dberkholz> i tend to think we should keep package-level metadata as close to the package as possible, even if it's not in the ebuild itself 20:07 <@leio_> Get each arch their own file perhaps, etc 20:07 < solar> being that we have not even discussed it. I'm not sure how you can dislike it. 20:08 <@dberkholz> i'd rather get rid of the centralized files than create more of them 20:08 <@leio_> and after there is such a plan, it might have a chance of being better than the status quo 20:08 <@dev-zero> solar: moving the keywords into one file <-- that's what I don't like 20:08 < solar> but to explain. Yes we want to reduce the overall resources needed in keywording. keywords can be broken out on a per cat basis also. 20:08 < solar> it's not a single file. 20:08 * solar digs up his example script to show ya 20:09 <@dev-zero> still, I don't see a benefit 20:09 < solar> really? 20:09 <@dev-zero> really 20:09 <@lu_zero> dev-zero it is nicer for minor arches or experimental branches 20:09 < solar> it's nicer from an overall pov. 20:09 <@dev-zero> solar: then show me 20:10 <@lu_zero> solar if you have many devs it doesn't change much 20:10 <@leio_> I don't need to cvs diff my packages when vapier keywords stuff without updating ChangeLog yet again ;p 20:10 < solar> right now every single dev both risks breaking the tree. Wastes tons of resources cvs up/diff/push of the entire ebuild dir. 20:10 <@dev-zero> lu_zero: that doesn't apply to most of our ebuilds in the tree 20:10 <@lu_zero> if you have too many devs the bare implementation would hit cvs limits 20:10 <@lu_zero> so right now I think the idea isn't that bad 20:10 < solar> look at it from a space savings also. There are just so many reason it makes sense 20:11 <@dberkholz> heh 20:11 <@dev-zero> and space saving isn't one of them 20:11 * ciaranm is curious as to how it would save space 20:11 <@dertobi123> space savings? maybe if we make it a single file 20:11 <@dertobi123> but having ~12.000 keyword files for each package wouldn't save space 20:11 <@leio_> there are no space savings to speak of 20:12 < solar> yes there is 20:12 <@leio_> there is quite some rsync wins probably however 20:12 < solar> not much but you save atleast 9 bytes per ebuild 20:12 <@dev-zero> doesn't matter 20:12 < solar> then you take into consideration that you can begin marking ranges 20:12 < solar> dev-zero: what do you mean? 20:12 <@leio_> I don't see how it saves anything 20:12 < solar> there are many rsync wins. 20:12 <@dev-zero> space: you saved 90MB, so what? 20:13 <@lu_zero> solar it would be something like generalizing .keywords file? 20:13 <@leio_> removing 20 bytes from each ebuild will make maybe 1% of them take one page less disk space 20:13 < solar> sec let me find my script. I really don't think you guys are getting it at all 20:13 <@Betelgeuse> hmm 20:13 <@Betelgeuse> Sorry 20:13 <@lu_zero> hi Betelgeuse 20:13 <@Cardoe> I'm here now 20:14 <@Betelgeuse> For the keywording it would be nice to be able to group keywords together for stuff. 20:14 <@dberkholz> alright, 2-3 more minutes and we need to wrap this bit up 20:14 <@Betelgeuse> There are plenty of things that go stable in sets. 20:14 <@dberkholz> just want to make sure the idea is clear to everyone 20:14 <@Betelgeuse> Like KDE, ant etc 20:15 < darkside_> the concept works, fwiw. we do it in prefix. asume all arches, mask when it breaks. 20:15 <@dev-zero> Betelgeuse: thanks, that was the first useful use case 20:15 <@Cardoe> We're arguing abstracts. 20:15 <@lu_zero> for common usage is the change user transparent? 20:15 <@Cardoe> solar: what exact setup did you have in mind? 20:16 <@dertobi123> Betelgeuse: which would require to have per category keyword files or a single global keyword file 20:16 <@Cardoe> solar: i.e. what would be the file and the syntax? 20:16 <@leio_> I'd hope solar can find some time to at least draft up a post to mailing list about it. Most people haven't read the beginning of the discussion covering the problems it solves, etc. And many discussions that happened on IRC on top of that kind of assumed prior knowledge and didn't specify many things over again iirc 20:16 <@lu_zero> developer wise will it be harder or simpler to do the common tasks? 20:16 < bonsaikitten> should end up simpler 20:16 < solar> I can't seem to find my example code at the moment. 20:16 <@dberkholz> ok 20:16 <@dberkholz> the idea is out there. we need to get it clarified and written down somewhere 20:17 <@dberkholz> is anyone willing to do that? 20:17 < solar> but it's quite simle. Assuming we all understand package.keywords/x11-wm/keywords 20:18 < ciaranm> i don't understand how you're going to keep it in sync or how you're going to avoid having to have a line for every single package... can't even keep package.mask clean currently. 20:18 <@leio_> I doubt package.keywords is unfamiliar to anyone here. It needs writing down what problems it solves, what benefits it has, and so on to properly be able to evaluate it and discuss about it 20:18 < solar> ugg 20:18 <@dertobi123> dberkholz: i'd expect solar to do so 20:18 <@dev-zero> solar: I think you can't avoid writing at least a draft 20:18 <@dberkholz> ciaranm: he's proposing a directory containing keywords files, kinda like /etc/portage/package.keywords/ or something 20:18 <@lu_zero> (or provide an implementation for us to play ^^) 20:18 < ciaranm> dberkholz: it's the "or something" bit 20:18 <@Betelgeuse> I could just go with being able to refer to an external file in KEYWORDS 20:19 <@dberkholz> actually the directory approach makes a bit more sense than the huge single file, although i'm still unsure about the overall approach. 20:19 < solar> You don't generally have 15 people editing at the same time. 20:19 <@dberkholz> but to return to my original question, who will pick this up and run with it? 20:19 < ciaranm> so you'd have zillions of =foo/bar-1.23 =foo/bar-1.23-r1 =foo/bar-1.23-r2 lines, and would have to ensure that they were all kept in sync with what's in the tree? 20:20 <@dev-zero> dberkholz: I also expect solar doing it 20:20 < solar> dev-zero: what do you expect? 20:20 <@dev-zero> solar: that you finally write at least a draft of it instead of just dumping your ideas here and expect us doing the work 20:20 < solar> I hope you all realize this functionality exists today 20:21 < solar> and the only thing that prevents us from using it is nothing 20:21 <@dberkholz> alright. 20:22 < solar> dev-zero: I never said i expected you to work. I asked the council to start thinking about it 20:22 <@Betelgeuse> The functionalilty to do lots of stupid things to the tree is available but I wouldn't want to see people doing them either. 20:22 < solar> if I have to spell out everything and hand it to you on a golden platter. Then umm. 20:22 <@dberkholz> to sum up, we've got a basic idea of the proposal, and we'd really like to have a stronger understanding of exactly what your idea is and its pros & cons 20:22 <@Betelgeuse> ^Doesn't necessarily mean this is stupid. 20:22 < solar> dberkholz: sure. 20:23 <@dberkholz> or just post the idea to the mailing list and ask other people to come up with the pros/cons bit 20:23 <@dberkholz> we need to move on to the next topic now 20:23 <@dberkholz> i would like to propose that we block any new features being added to the EAPI=3 set and postpone them to 4 (which can come at any point, it doesn't need to take forever) 20:24 <@lu_zero> ok 20:24 <@dberkholz> the goal being that we get something done now instead of continually adding features forever 20:24 <@dev-zero> I would like to set the deadline to Thursday, 16th 20:24 <@dev-zero> that's true, but a deadline needs to be announced beforehand which didn't happen so far 20:24 <@Betelgeuse> I would just set a deadline for Portage having implemented what's in EAPI 3. 20:24 <@dberkholz> because that's basically what's been happening over the past month or longer already, and this is supposedly "lightning" 20:25 <@dev-zero> that as well, yes 20:25 < ciaranm> so far as i'm aware, the things holding up EAPI 3 are the 'key' features, not the little bits 20:26 <@dberkholz> dev-zero: why does a deadline need to be announced? we can immediately start work on 4. 20:26 <@Betelgeuse> The idea behind deadline is to get people to work 20:26 <@dberkholz> just pick what's ready and do that as 3, things that are ongoing can be 4, things that are ongoing then can be 5, etc. 20:27 <@Betelgeuse> I do stuff best if I have a deadline to meet. Grated people might just not crre. 20:27 <@Cardoe> dberkholz: Why don't we just set rolling releases for EAPIs 20:27 <@Cardoe> whatever is ready every X days is a new EAPI 20:27 <@lu_zero> works for me 20:27 < darkside_> agile EAPI 20:27 <@dberkholz> i kinda like that, actually. 20:27 <@dev-zero> there is nothing agile in that 20:27 <@Betelgeuse> Cardoe: if there's something substancial there then sure 20:28 <@dev-zero> yeah, but bumping the eapi just for minor foo things is just nonsense 20:28 <@dev-zero> why not do it like the kernel development cycle 20:28 < ciaranm> the problem with that is that difficult things will just get postponed indefinitely 20:28 <@lu_zero> why? 20:29 <@lu_zero> you start working on it with a target 20:29 <@lu_zero> that isn't the next release window 20:29 < ciaranm> because as soon as a feature starts hitting the "needs detailed discussion" target, it just gets postponed over and over and no-one ever makes a decision 20:29 <@lu_zero> once it's done you can get it released 20:29 <@dberkholz> dev-zero: why? if the feature's there, somebody is clearly expecting to benefit from it. making them wait another X months because there's no "important enough features" sucks 20:29 <@dev-zero> dberkholz: oh, that's not what I meant 20:30 <@dev-zero> dberkholz: what I meant was: having defined "open for ideas/requests", "implementation", "deployment" phases 20:30 < ciaranm> "once it's done" is only good for things that will get done without a degree of coordinated work. it'll be fine for most things, but it's not a complete solution. 20:30 <@Betelgeuse> ciaranm: With new EAPIs I don't think making decisions has been the problem. 20:30 < mpagano_> /win 20 20:30 <@Betelgeuse> The problem is getting Portage to implement things. 20:30 <@Cardoe> Do we have any targets to get anything done today? 20:30 < ciaranm> Betelgeuse: with EAPIs 1, 2 and 3 all being "what's available" stuff, we've not been able to put in "what's necessary" yet 20:30 <@Cardoe> Cause I've unfortunately seen only 30 minutes of unproductive arguing 20:31 <@dev-zero> Cardoe: and you keep adding to that 20:31 * solar never got a chance to speek. So the first 10 was wasted. 20:31 <@dev-zero> dberkholz: let's vote on whether or not we have feature freeze for eapi-3 now 20:31 <@dberkholz> sounds good. 20:31 <@lu_zero> ok 20:31 <@dev-zero> dberkholz: and discuss a standard way for developing future eapis on the ml 20:31 <@leio_> what defines what features are frozen there? 20:32 <@dev-zero> since we can't fully control what features get implemented in time in portage 20:32 <@dberkholz> leio_: i suggested what was already discussed at the last meeting is the maximal set, and things can be cut from there 20:32 < ciaranm> leio_: just say "no to anything that's not already in the draft, and maybe to anything that is"? 20:32 <@dev-zero> the feature freeze is more a: that's what we like to have, things can be dropped if not implementable in time 20:32 <@lu_zero> btw freezing the spec or the implementation? 20:32 <@dberkholz> spec 20:32 < ciaranm> lu_zero: the spec isn't ready to be frozen 20:32 <@dev-zero> there is no implementation 20:33 <@dberkholz> well, the features in the spec, anyway. 20:33 < ciaranm> lu_zero: the list of... what dberkholz said 20:33 <@lu_zero> ok 20:33 < ciaranm> some of those features still have things like "TODO: we need to work out exactly what this does" 20:33 <@dberkholz> so, let's vote on blocking new feature addition to EAPI 3 and postponing them to 4. 20:33 <@dev-zero> dberkholz: what about the other meeting topics, do they fall into the category of eapi-4 or later? 20:34 <@dberkholz> dev-zero: from agenda, "This [the block] specifically applies to anything not already discussed as of last meeting, including the 2 below items." 20:34 <@leio_> I'm cool with mtime preservation when it's just setting in writing what portage already does 20:34 <@leio_> (and having that guarantee for the future since EAPI-3), but if there's controversy, postponing might be good. 20:34 <@dberkholz> not really a big deal if you want to change that, though. 20:35 < ciaranm> mtime preservation as "what portage already does" has issues. it's not something that should be going in without discussion. 20:35 <@leio_> lets say then - if the discussion ends up with concluding something that portage already implements, we can add it to EAPI-3 if it's not already finalized and shipped 20:35 <@dev-zero> leio_: no 20:35 <@dberkholz> ok, 3 choices. A -- block as of already-discussed features. B -- include mtime preservation. C -- no block yet. 20:35 <@dberkholz> take your pick 20:36 <@Betelgeuse> C 20:36 <@dberkholz> A 20:36 <@dev-zero> C 20:36 <@leio_> hum 20:36 <@Cardoe> What do we gain exactly from A and B? 20:36 <@dberkholz> getting an implementation sometime this year, one hopes. 20:37 <@dertobi123> and when's the block/deadline for C? 20:37 <@Cardoe> Arbitrarily picking a list won't guarantee anyone will code it in Portage? 20:37 <@Betelgeuse> indeed 20:38 <@lu_zero> keeping the list small raises the chances 20:38 <@leio_> B, but that doesn't mean already in the list things can't get dropped out if they don't get implemented on time (what time?) or there are open questions without concensus 20:38 <@dberkholz> if people want the 'no block yet', we'll have to figure out where to go from there, when to have a deadline, etc. 20:38 <@dev-zero> s/C/A 20:38 <@Cardoe> ciaranm has a point that several of the items on there vague. 20:38 <@lu_zero> A 20:38 < ciaranm> once we know which features are candidates, fixing the vagueness isn't too tricky 20:38 <@dberkholz> 3 A's, 1 C, 1 B. 20:38 <@dertobi123> so well, A then to at least have a chance of making it a "quick" eapi-3 20:38 <@Cardoe> ok fair enough 20:38 <@Cardoe> then A 20:39 * ciaranm was planning to do a mass pms fixup over the weekend anyway so fauli's cheatsheet stuff can go in 20:39 <@dertobi123> ciaranm: nice 20:39 <@Cardoe> ciaranm: you'll generate the cheat sheet as a page at the end? 20:39 < ulm> i'd really urge to council to act on the mtime issue 20:39 < ciaranm> Cardoe: see the pms mailing list. not quite. 20:39 < ulm> should be very easy to implement 20:39 < ciaranm> Cardoe: we have plans for a document reformatting and a two pdf thing. probably too off-topic for here. 20:39 < darkside_> and the prefix variables. 3 lines in ebuild.sh and it is done. (already done actually) 20:40 <@dev-zero> ulm: as far as I've seen it has some pitfalls 20:40 < ulm> dev-zero: everything is better than leaving it unspecified 20:41 <@dberkholz> ok, four A's it is. feature block as of already-discussed features. 20:41 < solar> w15 20:42 <@dberkholz> those of you with a pet feature, feel free to respond to the summary on -dev if you have some compelling reason why it's super easy to get in and can't be pushed back. keep in mind there's no reason we need to take forever for EAPI 4, either 20:42 * ciaranm cries at dberkholz's last remark 20:43 <@dev-zero> dberkholz: we did a feature freeze 20:43 <@dev-zero> dberkholz: nothing comes in anymore 20:43 <@lu_zero> we could take the 4 to experiment with release methods 20:43 < grobian> dberkholz: does that mean you won't discuss the topics of your agenda anymore? 20:43 <@dev-zero> we can discuss it as part of eapi-4 20:44 <@dev-zero> or defer the discussion and discuss eapi-independent topics 20:44 < ulm> this so sucks :( 20:44 <@dberkholz> ciaranm: people are going to do it anyway. =) if we attempt to "forbid" them somehow, it just erodes our authority. 20:44 < ciaranm> dberkholz: should've just insisted upon it being in 4! 20:45 < ciaranm> also, if anyone wants me to rewrite pms history to get their feature in in such a way that it looks like it was before the deadline, send me a hundred quid in nonsequential used ten pound notes 20:45 * ciaranm giggles 20:45 <@dberkholz> we should start discussing the features regardless, because the whole point is that EAPIs shouldn't take forever 20:46 <@dberkholz> i'm fine if we approve 4 a month after 3. 20:46 < ciaranm> sure. but for 4, rather than "4 unless you can come up with a convincing argument for it being in 3" 20:46 < ciaranm> because everyone thinks their arguments are convincing 20:46 <@dev-zero> dberkholz: after having 3 implemented, please 20:46 <@Betelgeuse> Instead of discussion let's all just implement things. 20:46 <@dertobi123> zmedico: can we set a deadline on when eapi3 stuff is implemented in portage? i.e. when we can compile a final list of eapi-3 features? 20:48 <@dev-zero> what about 42 days from now? 20:49 < zmedico> dertobi123: sure, I guess so. 20:49 < ciaranm> zmedico: did you have [use(+)] done? that was the critical feature for 3 20:50 <@dertobi123> zmedico: so what about an estimate? ;) 20:50 < zmedico> ciaranm: I haven't done anything yet but none of it seems particularly difficult 20:51 <@dberkholz> grobian: looks like we're about to run out of time today, but i'm happy to discuss those prefix features in general at any point ... i've already put it on the next agenda -- http://dev.gentoo.org/~dberkholz/20090423-agenda.txt 20:51 < grobian> dberkholz: great 20:52 < zmedico> dertobi123: if I've got a firm list of things that are definitely going in then I can probably have it done in a week or two 20:52 <@dberkholz> let's go with next meeting, then 20:52 <@dberkholz> april 23 20:52 <@dertobi123> sounds good 20:52 <@Betelgeuse> Just to note if someone needs something from me I will be in Spain next week. 20:52 <@dev-zero> ok 20:52 <@dertobi123> bleh, everyone's out for holidays :( 20:53 < ciaranm> i can have pms ready (with features being easily removable) by monday, assuming i've got at least some kind of mobile phone coverage over the weekend... 20:53 <@leio_> So anyone from Spain can find you and get what they want? 20:53 <@Betelgeuse> leio_: If someone wants to come to visit my hotel for a review, sure 20:54 <@leio_> I should send armin76 to you or something. Any updates on that benchmarking stuff, or what's the next topic again? 20:54 <@dberkholz> so, we've got about 5 minutes. 20:55 <@dberkholz> i've already started the agenda for next meeting to try helping everyone get better prepared 20:55 <@dev-zero> dberkholz: I assume you're putting the other topics we didn't discuss today on that list as well? 20:55 <@dberkholz> yeah, i put them there. prefix, mtime, and the changing ebuild features thing. 20:56 <@dberkholz> we'll have to sort things out a bit as the time approaches 20:56 <@dberkholz> hopefully some of that can become clearer on the lists over the next 2 weeks 20:56 <@Betelgeuse> leio_: Yeah slacker. 20:56 <@Betelgeuse> Forgot mainly. 20:56 <@dev-zero> yeah, and let's try to start discussing things 10 days before the next meeting instead of 1 day before 20:57 <@dberkholz> sorry about that for my lack of participation, i've been really busy w/ work. that'll be done a week from now. 20:57 <@Betelgeuse> dberkholz: well you still do more than I have lately 20:58 <@dev-zero> I have to admit that I wasn't so active last week but the OpenExpo took some time as well... 20:58 <@dertobi123> dev-zero: heh 20:58 <@dev-zero> dertobi123: didn't even have time to upload the picture of you and maekke ;-) 20:58 <@dberkholz> ok, today's meeting is over. as usual, i strongly encourage everyone to take topics to the lists that we didn't get to today, so we can get some action without waiting 2 weeks. 20:58 <@dertobi123> dev-zero: oh! ;) 20:59 <@dberkholz> and council members in particular, please do what you can to actively participate on those topics in particular 21:00 <@dev-zero> or do help zmedico with the implementation of eapi-3 features :)