path: root/meeting-logs/20090409.txt

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 <tanderson>	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 <tanderson>	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 :)