15:01 <@dberkholz> ok, let's get started
15:01 <@Cardoe> Betelgeuse: yes?
15:01 <@Betelgeuse> Cardoe: just to find out that you are here
15:01 -!- ferdy [n=ferdy@exherbo/developer/ferdy] has joined #gentoo-council
15:01 <@Cardoe> Betelgeuse: I've been here talking for the last hour
15:01 <@dberkholz> Betelgeuse, Cardoe, dberkholz, dertobi123, leio-dl are here
15:01 <@Betelgeuse> dev-zero:
15:01 <@dberkholz> lu_zero, dev-zero -- pong please
15:02 <@dev-zero> dberkholz: pong
15:02 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has joined #gentoo-council
15:02 <@dberkholz> lu_zero: check in again when you're back
15:02 < fmccor> lu_zero was here 9 minutes ago
15:02 <@dberkholz> let's start
15:03 <@dberkholz> anyone mind if we talk briefly about the path to EAPI=3, even though it wasn't on the draft agenda?
15:03 <@Betelgeuse> There won't be a shortage of ideas the main deciding thing is zac.
15:03 <@Betelgeuse> Unless someone gets down to coding.
15:04 <@dberkholz> zmedico: around?
15:04 <@Betelgeuse> As can be seen with GLEP 55 if we rely on zac we really can't make much plans.
15:04 <@dev-zero> Betelgeuse: for at least one issue on the task there's already a patch for portage
15:04 < ciaranm> half the things on the list are five minute bash jobs
15:04 <@dev-zero> second, some issues are pretty much isolated and don't need much portage knowledge
15:05 <@Cardoe> We don't necessarily have to rely on Zac. Most of the items are really basic and can be coded by someone with 30 min time.
15:05 <@Betelgeuse> good
15:05 < ciaranm> the one that's slightly non-trivial is [use(+)] deps (assuming we like that syntax), and afaik that's considered the driving force behind EAPI 3
15:05 <@dev-zero> yes
15:05 <+tanderson> hi, I'm here now
15:05 <@Betelgeuse> Well repoman support would help a lot too.
15:05 <@dev-zero> and the multislot dep issue
15:05 <@Cardoe> ciaranm: was that for handling the missing case?
15:05 < ciaranm> Cardoe: yeah
15:06 <@dberkholz> which line is that on the spreadsheet?
15:06 <@dberkholz> use(+)
15:06 <@dev-zero> 6
15:06 <@Cardoe> ciaranm: can you give a quick description of the syntax. The spreadsheet kinda is weak on it and I'd also like to have a description of the syntax for the logs.
15:06 <@Betelgeuse> dev-zero: please post a link so it gets logged
15:06 <@leio-dl> [use(+)] has the same portage stock message issue as other USE deps, but that's a topic for ml and possibly separate thing
15:06 <@Cardoe> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ is the spreadsheet and #6 is what we're talking about
15:07 < ciaranm> Cardoe: the syntax exheres-0 uses is foo/bar[flag(+)] and foo/bar[flag(-)]
15:07 <@dev-zero> here are the eapi-3 feature proposals: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
15:07 <+tanderson> I need to catch up :\
15:07 < ciaranm> where (+) means "pretend it's on if foo/bar doesn't have flag in IUSE"
15:07 <@Cardoe> dev-zero: they're missing a bunch that ciaranm suggested and I'd like to see merged in.
15:07 <@Cardoe> ciaranm: thanks
15:07 <@dev-zero> Cardoe: hmm, which ones?
15:08 <@Betelgeuse> I don't really see it solving the remove use flags problem unless we always start to use these atoms.
15:08 <@dev-zero> Betelgeuse: that's true
15:08 < ciaranm> Betelgeuse: until someone removes the use flag in a newer version, though, you don't know what your dep will want
15:08 <@Betelgeuse> You should always check reverse stuff any way.
15:08 < ciaranm> if you're currently foo/bar[baz], and new bar has no baz, you don't know in advance whether it's because baz is always on or has been removed or what
15:09 <@Betelgeuse> ciaranm: I know but I was referring to the spreadsheet.
15:09 <@Cardoe> I think it's a good syntax as any unless there are any technical objections.
15:09 < ciaranm> so if you do foo/bar[baz] until you know, the repoman can flag it down for you once a new foo/bar comes along
15:09 <@leio-dl> we just need tools to show automatically what depends on an IUSE in any way to deal with it
15:09 * ciaranm really can't type tonight
15:10 <@Betelgeuse> dev-zero: One thing to add is doexamples
15:10 <@Cardoe> ok lemme speed this up.
15:10 <@leio-dl> but repoman will only tell it if you run it inside the package that has foo/bar[baz] in depends, not when you are running it inside foo/bar after removing baz from IUSE
15:10 <@dev-zero> Betelgeuse: good point
15:10 < ciaranm> leio-dl: yup. fortunately, people do global tree scans regularly to catch that sort of thing.
15:10 <@dberkholz> there's some point where we have so many do* actions that it's harder to remember them all than to do an insinto..
15:10 <@leio-dl> always after the fact. Lets move on
15:11 < ciaranm> leio-dl: there's no nice easy solution to dealing with reverse deps, and use deps don't really alter that
15:11 <@Cardoe> Do we want [use(+)] deps to go into the EAPI-3 draft? dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero?
15:11 <@Cardoe> I say yes.
15:11 <@leio-dl> yes
15:11 <@dertobi123> yep
15:11 <@dev-zero> yes
15:11 <@dberkholz> fine w/ me
15:11 <@Betelgeuse> dberkholz: well in the long term we should more helper stuff to the tree
15:11 <@Cardoe> dertobi123: sorry for missing you off
15:11 <@dertobi123> Cardoe: :P
15:11 <@Betelgeuse> Cardoe: sure
15:11 <@Cardoe> dertobi123: too many d's
15:12 <@dertobi123> heh
15:12 <@Cardoe> Ok. Next item on the draft.
15:12 <@Cardoe> pkg_pretend()
15:12 <@dberkholz> we'll have to vote for higher council nick diversity next time.
15:12 <+tanderson> bwahaha
15:12 <@dberkholz> i am totally for pkg_pretend
15:12 <@Cardoe> I would like to see pkg_pretend() useful for displaying USE conflicts
15:13 <@Cardoe> http://bugs.gentoo.org/show_bug.cgi?id=75936
15:13 <@dberkholz> there are so many ways it's useful
15:13 <@Cardoe> To allow the developer to put a description behind it.
15:13 <@dev-zero> yes, me too, but we should still try to find a more pm-based solution for USE conflicts
15:13 <@Cardoe> because the current way Portage displays it sucks
15:13 <@dberkholz> telling people we're gonna break their system before a merge instead of after
15:13 <@Cardoe> and users are confused
15:13 <@dberkholz> gentoo sysadmins have complained to me about that so many times
15:13 <@Cardoe> pkg_pretend in draft EAPI-3.... dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero, dertobi123?
15:13 <@dev-zero> yes
15:13 <@Cardoe> yes
15:14 <@dberkholz> 20:12 < dberkholz@> i am totally for pkg_pretend
15:14 <@Betelgeuse> Cardoe: Do we need to go through one by one?
15:14 <@dertobi123> yes
15:14 <@leio-dl> abstain (haven't read and thoguht about it enough)
15:14 <@Betelgeuse> Is there anything people disagree on?
15:14 <@Cardoe> Betelgeuse: I'm looking for us to nail down a "draft" list.
15:14 <@Cardoe> That we can hand over to the PM maintainers to implement
15:14 <@Cardoe> They come back to us once we've got some code and we'll formally resolve the differences and finalize EAPI-3
15:15 <@Betelgeuse> Cardoe: What good does that do if we are tied to Portage implementing things?
15:15 < ciaranm> can always take things out if it turns out portage can't do them quickly
15:15 <@dberkholz> how about we come up with a list of things on that spreadsheet that any of us disagrees with instead
15:15 <@Cardoe> Fine
15:15 <@Betelgeuse> I would propose as to set a time and then see what Portage has then.
15:15 <@dberkholz> it'll take a while to go through 20-something positively
15:15 <@Betelgeuse> And use that for EAPI 3.
15:15 <@dev-zero> I already cancelled some features out (those with prio=99)
15:16 <@Cardoe> dev-zero: please add a reference to bug #75936 to item #1
15:16 < Willikins> Cardoe: https://bugs.gentoo.org/75936 "method for handling conflicting USE flags at --pretend time required"; Portage Development, Core - Ebuild Support; NEW; ciaran.mccreesh@...:email@example.com
15:16 <@Betelgeuse> I say a month is fine.
15:16 <@dev-zero> Cardoe: I'm sorry, but that's not the same thing
15:17 <@Betelgeuse> Any comments?
15:18 <@dberkholz> so basically request a specific list of features in portage, then take whatever's done in a month and call it 3?
15:18 <@dertobi123> putting those marked with priority 1 to 3 on a draft and look in month what we have implemented in portage would work for me
15:18 <@dertobi123> in a month*
15:18 <@Betelgeuse> dberkholz: it can implement more too
15:19 <@dberkholz> sorry, didn't understand that
15:20 <@Betelgeuse> dberkholz: I don't think we need to restrict ourselves to the items on that list of there is more implemented (if this is likely is of course another matter)
15:20 <@dberkholz> all i'm saying is that we actually provide a list of stuff that we want, instead of having this list of random features that a million people have proposed, which we may or may not end up approving
15:21 <@Cardoe> Betelgeuse: we're not restricting outselves
15:21 <@Cardoe> We're providing a list of stuff we'd like to see
15:21 <@dberkholz> so we pre-approve features before they're implemented
15:21 <@dev-zero> that's true, but it would be good if we limit ourselves to certain points and see that those get really implemented
15:21 <@Betelgeuse> dev-zero: The easiest way is to divide the features between council members or others to code
15:21 -!- keytoast1r [n=tobias@...] has quit [Client Quit]
15:21 <@leio-dl> I don't like pre-approving, if expressed that way
15:22 <@dev-zero> Betelgeuse: ok, fine by me
15:22 -!- theinlein [n=tobias@gentoo/developer/keytoaster] has joined #gentoo-council
15:22 <@dberkholz> leio-dl: what's your problem with it?
15:22 <@Cardoe> We're sifting through the list of proposed features on all the mailing lists
15:22 <@Cardoe> rejecting certain ones out right
15:22 <@Cardoe> and prioritizing some based on the needs and requests
15:22 <@Cardoe> and giving that list to people to code
15:22 <@Cardoe> then we'll check back with what's coded in a month
15:22 <@Cardoe> and go from there
15:22 <@leio-dl> my problem is that for example we haven't actually been able to test this feature, and before actual approving we could and something turns out. That's an example
15:22 -!- theinlein is now known as keytoaster
15:23 <@dberkholz> pre-approving doesn't mean pre-requiring
15:23 <@dberkholz> it means if things work out well, it's in. it could still fail at the implementation step
15:23 <@leio-dl> pre-approving worded like that sounds like we can't end up rejecting it
15:23 <@leio-dl> if it turns out to be a bad idea by then, regardless of the implementation
15:23 <@Cardoe> if it turns out to be a bad implementation or works out to be poorly thought out after further discussions we drop it
15:23 < ciaranm> leio-dl: all of these features are easy to turn on or off in the package manager
15:23 <@dev-zero> that's why you usually have developers at the requirement meeting
15:24 <@Cardoe> It's a wish list
15:24 <@Cardoe> dev-zero: unfortunately we can't force the developers of PMs to be on here
15:24 <@leio-dl> wish list, sure. Just avoid the term pre-approved and I'll be happy
15:24 <@dev-zero> Cardoe: no, it's a requirement list
15:24 <@dev-zero> Cardoe: we have at least one developer of a package manager here
15:25 <@Cardoe> dev-zero: indeed we do and we appreciate it.
15:25 <@Cardoe> dev-zero: but alas the others did not come.
15:25 <@dev-zero> Cardoe: and the prio=1 features have been implemented in one package manager, so a proof-of-concept is done
15:25 <@leio-dl> ciaranm: No, they are not. If the ebuild says an EAPI, it has to support it fully not have something turned off
15:25 <@Cardoe> leio-dl: he meant as part of development and testing
15:25 < ciaranm> leio-dl: no, i mean, we can implement features in the package manager, but not have them supported for any EAPI
15:26 <@leio-dl> sure, you can implement what you want :)
15:26 <@Cardoe> Honestly folks. This is a rather pointless debate.
15:26 <@Cardoe> We've got a list with priorities
15:26 <@dev-zero> yes
15:26 <@Cardoe> It's done
15:26 <@Cardoe> Move on
15:26 <@Cardoe> dberkholz: what's the next agenda item?
15:27 <@dberkholz> it was overlay masking, but we've already got an action there
15:27 < ciaranm> leio-dl: have a look at http://git.pioto.org/gitweb/paludis.git?a=tree;f=paludis/repositories/e/eapis;h=18e91e4a6e08e6160f400;hb=master to see what i mean. there's no harm in experimentally or provisionally implementing something in a package manager and then just not using it if it turns out it sucks
15:27 <@dberkholz> leio-dl just needs to follow up on list, which he's gonna do by saturday
15:27 <@Cardoe> dberkholz: sounds good.
15:27 <@Cardoe> dberkholz: next item?
15:27 <@dberkholz> then we've got the live ebuild stuff
15:28 <@dberkholz> the existing writeup really doesn't address the things i was hoping it would, along the lines that antarus did for 55
15:28 <@Cardoe> frankly the more we look at the live stuff. the more I feel its lacking
15:28 <@dberkholz> i'm wondering whether i need to get involved with that
15:29 <+tanderson> uh, I was supposed to write a comparison, no?
15:29 <@Cardoe> tanderson: yep
15:29 <+tanderson> at least that what everybody agreed on for the summary
15:29 <@Cardoe> The only thing I'd like to see from GLEP 54 is a defined way of storing the revision information used by the build
15:29 <+tanderson> so How did what I do not address what was wanted?
15:30 <+tanderson> Cardoe: Yeah, I hope to work on that soon. Thankfully, classes have eased up a bit
15:30 < ciaranm> Cardoe: storing revision information is largely an unrelated issue. getting that whole thing right is best addressed as stages two and three of a staggered plan
15:30 <+tanderson> yeah, All we have to agree on is that it's possible and a good plan to do it with GLEP 54, or not..
15:31 <+tanderson> er, s/we/you obviously :P
15:31 <@Cardoe> ciaranm: ok fine.
15:31 <@Cardoe> ciaranm: then I'd like a documented way for the user to specify a specific revision
15:31 <@Cardoe> right now we've got ESVN_REVISION and EGIT_REVISION
15:31 < ciaranm> Cardoe: that's stage two, or possibly stage three if it's split in four
15:32 -!- kICkar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council
15:32 <@dberkholz> they're not really compared at all ... there's a document that has descriptions for both of them, and a problem or 2 picked out with each. there's no tie-in to the actual requirements of what this needs to do.
15:32 < ciaranm> Cardoe: solving the entire live sources problem is a lot of work, and there're a lot of very non-obvious pitfalls. trying to do it all at once means it'll never get anywhere.
15:32 <@dberkholz> it's clear to me that my mental picture doesn't match with what i actually requested
15:32 <@Cardoe> ciaranm: fair enough
15:33 <@Cardoe> ciaranm: so we're just going to say this addresses the -9999 ebuild
15:33 <@Cardoe> Is Portage using PROPERTIES=live?
15:33 < ciaranm> Cardoe: right. the glep *just* addresses the ordering problem, and nothing else.
15:34 < ciaranm> PROPERTIES=live isn't necessarily bad. it's just not related to what the glep's trying to solve.
15:34 <@Cardoe> ciaranm: well, we could say that if you make a -scm.. you have to put PROPERTIES=live
15:35 <@Cardoe> in there
15:35 < ciaranm> really... PROPERTIES=live is just a lousy way of sort of attempting some of part two or three...
15:35 <@Cardoe> ciaranm: my idea here is let's get GLEP 54 into EAPI=3 and not make people wait until EAPI=4 to really work with it
15:35 < dleverton> Is there any case when it would be sensible to have -scm without PROPERTIES=live, or vice versa?
15:35 < ciaranm> dleverton: the PCI IDs list, arguably
15:36 <@Cardoe> ok fine
15:36 <@Cardoe> we'll come back to it
15:36 <+tanderson> ciaranm: is that checking out a static revision?
15:36 <@dev-zero> Cardoe: the original motivation behind EAPI=3 was to have it fast
15:36 <@Cardoe> dev-zero: as is my motivation right now.
15:36 <@dev-zero> Cardoe: things like G55, G54 and a couple of more issues which can take month are not suited
15:36 < ciaranm> 54's a lot easier with 55, which puts it into "not fast" territory unfortunately
15:36 <@Cardoe> Does any council member have a technical issue to GLEP 54?
15:37 <@lu_zero> Cardoe the glep should be specified better
15:37 <@lu_zero> but I said that already
15:37 <@leio-dl> I need more time to be sure personally
15:37 <@dev-zero> Cardoe: and I want a reference implementation
15:37 <+tanderson> lu_zero: well, considering it's only addressing part 1, I'm not so sure..
15:37 <@Cardoe> dev-zero: so do I
15:37 < ciaranm> kdebuild-1's a reference implementation for both 54 and 55
15:38 <@lu_zero> tanderson it's addressing the last part of something bigger
15:38 <@lu_zero> you usually do not start from the roof
15:38 < ciaranm> -scm is the first part, not the last part, because it's easy and doesn't need the other parts to be useful
15:38 <+tanderson> lu_zero: well, I think the first part is getting correct ordering
15:38 <@lu_zero> ciaranm it's uses are debatable at best
15:38 <@dev-zero> lu_zero: I agree with tanderson
15:39 < ciaranm> lu_zero: tell that to the people using -9999, -20099999 and so on
15:39 <@lu_zero> ciaranm 9999 it's a value like others
15:39 < ciaranm> lu_zero: which is the problem
15:39 <@dev-zero> ok, I don't see that we get to an end here, do you?
15:39 <@dertobi123> not really ...
15:39 <@lu_zero> you can enforce ordering otherwise
15:40 < ciaranm> i honestly don't see an end until there's a vote, because lu_zero isn't ever going to agree to -scm
15:40 <@lu_zero> like preventing people using pkg-1234545677
15:40 <@lu_zero> that said my only concern is getting more people agree on it, so if somebody adds more meat to glep 54 I won't be against it
15:41 <+tanderson> lu_zero: what kind of meat?
15:41 <@dev-zero> and I still fail to see what needs to be added
15:41 <@lu_zero> dev-zero if I propose you to allow utf8 for names and latin numbers for version
15:42 <@lu_zero> you'd consider me crazy
15:42 < ciaranm> latin numbers for versions is doable
15:42 <@dberkholz> back in 5, gotta take care of something.
15:42 <@lu_zero> ciaranm anything is doable
15:42 <@lu_zero> even utf8 numbers
15:43 < ciaranm> lu_zero: actually no. i could list several proposals regarding versioning that are technically unimplementable.
15:43 <@lu_zero> that alone should make you wonder if is worth it
15:43 <@lu_zero> if there is an use
15:43 < ciaranm> the use for -scm is replacing -9999 etc
15:43 <@lu_zero> the use of utf8 names is to allow crazy names in programs
15:44 <@lu_zero> that doesn't make it more agreable
15:44 < ciaranm> lu_zero: how many programs can you think of that use utf-8 names?
15:44 <@lu_zero> ciaranm I hope none
15:44 < ciaranm> lu_zero: compare that with the number of packages for which people are shipping -scm ebuilds
15:44 <@dev-zero> lu_zero: I think you're getting far away from the real problem
15:44 <@lu_zero> ciaranm I hope none as well
15:44 <@lu_zero> since means that either upstream or the packager is insane
15:45 < ciaranm> lu_zero: there're lots of packages using -9999 or equivalent. most are masked, fortunately, but people find them useful.
15:45 <@lu_zero> ciaranm they are masked since they are unstable by definition
15:45 <@lu_zero> and they are scarce
15:45 < ciaranm> lu_zero: yes. and? they're still there, so we should support them well.
15:45 < ciaranm> lu_zero: look at how many scm-related eclasses there are in the main tree. are you saying they should be removed?
15:45 <@lu_zero> we should support them within the limit of usefulness/effort ratio
15:46 <@lu_zero> ciaranm they can be used even w/out requesting for fluid revisions
15:46 < ciaranm> the only effort for -scm is discussing things with you... it's easy to implement
15:46 <@lu_zero> see mythtv and their ustream
15:46 <@lu_zero> upstram
15:46 <@lu_zero> sigh I cannot spell
15:47 <@Cardoe> lu_zero: I'm the MythTV guy..
15:47 <@lu_zero> as a -9999 user I'll be glad to have something simpler
15:47 <@Cardoe> Based on what GLEP 54 proponents are trying to say is
15:47 <@Cardoe> let's that be the next step
15:47 <@Cardoe> let us just get the basics down
15:47 <@lu_zero> Cardoe IIRC you had to use constant revision sometimes
15:48 <@Cardoe> yep
15:48 <@Cardoe> But this GLEP won't address all uses of svn/git/cvs/bzr etc
15:48 <@Cardoe> just the -9999 usage
15:48 <@Cardoe> which I don't use
15:48 <@lu_zero> right
15:48 <@Cardoe> I'll have to write a new GLEP
15:49 <@dev-zero> ok, result of this discussion?
15:49 <@dberkholz> back
15:50 <@dev-zero> dberkholz: right in time
15:50 <@Cardoe> lu_zero: I say you and I work on another GLEP on top of this
15:50 <@lu_zero> Cardoe agreed
15:50 <@Cardoe> which brings up a point.. why aren't the EAPIs a GLEP?
15:50 <@Betelgeuse> Cardoe: we tagged PMS last time
15:51 < ciaranm> Cardoe: because we're lazy, and a PMS branch is easier
15:51 <@Cardoe> Fair enough
15:51 <@Cardoe> I like lazy
15:51 <@lu_zero> thehe
15:51 <@Cardoe> next item?
15:51 <@lu_zero> everybody feels
15:51 < ciaranm> otherwise we'd have to rst them for GLEPs as full proposals, and then work that into PMS as diffs
15:51 < solar> remove keywords from ebuilds.
15:51 < solar> ciaranm: can your pkg mgr handle that?
15:51 < solar> ie. profiles/package.keywords
15:52 <@dberkholz> ...?
15:52 < ciaranm> solar: we don't use keywords from profiles at all currently. we could, easily enough, but it won't work for gentoo until gentoo-x86 is a tenth of its current size and using git instead of cvs
15:52 < solar> it wont work?
15:52 < ciaranm> it doesn't scale to what arch teams do
15:53 < solar> it works today in everything else. I just want to make sure i don't cause any segvs
15:53 -!- togge [n=togge@gentoo/contributor/togge] has quit [Remote closed the connection]
15:53 < ciaranm> this was investigated three or four years ago... iirc agriffis an / or g2boojum
15:54 < ciaranm> basically... the cvs tree is so big and slow, you'd never be able to commit anything because of conflicts if everyone's editing a single file all the time
15:54 < solar> ciaranm: well the scaling thing does not really hold true anymore.
15:54 < solar> and conflict is not any more of a problem than say ppl editing other package.
15:54 <+tanderson> ciaranm: wouldn't you get merges rather than conflicts?
15:54 < ciaranm> solar: honestly, i suggest you bring it up after gentoo's using git and lots of smaller independent repositories
15:55 -!- togge [n=togge@...] has joined #gentoo-council
15:55 <@Betelgeuse> Is this really something we need to discuss atm?
15:55 < ciaranm> tanderson: if you're lucky
15:55 < solar> files. Anyway. I plan to go down this route with a bunch of other ppl. So
15:55 <@dberkholz> i've gotta head out in the next 5-10 min, so i'd like to get through the next topic as much as possible
15:55 <@Betelgeuse> dberkholz: fine by me
15:55 <@dev-zero> me too
15:56 <@lu_zero> ok
15:56 <@dberkholz> basically wrt glep 55, we really need the information from people that we requested at the last meeting and expected to hear back about a week ago
15:56 <@dberkholz> so what's the deal?
15:56 <@Betelgeuse> I can't benchmark something that's not there.
15:56 <@Betelgeuse> Zac promised me two weeks ago to do it
15:56 <@Betelgeuse> But never did it.
15:56 <@dberkholz> alright
15:56 <@Betelgeuse> So it seems I must implement it myself.
15:56 <@lu_zero> did he tell something about it?
15:57 <@Betelgeuse> lu_zero: See his mail on gentoo-council
15:57 <@lu_zero> just that?
15:58 <@dberkholz> Betelgeuse: ok, can you check back in with zac about that timeframe and drop a post to -council?
15:58 <@Betelgeuse> lu_zero: yeah haven't heard anything yet since that
15:58 <@dberkholz> it is still "this week" after all
15:58 <@lu_zero> right
15:59 <@Betelgeuse> My opinion is to approve 55 and put a GSoC project by an experienced dev to redesign the tree format that always uses .ebuild
15:59 <@dberkholz> ciaranm: i was hoping to see some benchmarks from you. could you post them?
15:59 <@Betelgeuse> Can actually nail down PMS and solve other long standing issues.
15:59 <@lu_zero> I have to ask him something about multislot as well
15:59 <@lu_zero> Betelgeuse would be interesting
16:00 <@Betelgeuse> If this doesn't happen before we have a need for global scope changes we can fall back on 55.
16:00 <@Betelgeuse> In the mean time.
16:00 < ciaranm> dberkholz: just under 50% slowdown in metadata access times in the 'valid cache' case
16:00 <@lu_zero> ciaranm something we could try ourselves?
16:00 <@dberkholz> ciaranm: i'd really love to see the numbers on times for each case
16:01 < ciaranm> dberkholz: for invalid cache cases you can't measure it since bash is a thousand times slower than using the cache
16:02 < ciaranm> lu_zero: why? planning to benchmark it on an ssd just to screw with the results? :P
16:02 <@lu_zero> ciaranm planning to read the patch and see how works
16:02 <@dberkholz> ciaranm: hot cache, cold cache? what are the numbers in seconds?
16:03 <@lu_zero> the more people trying the more shared is the decision upon it
16:03 < ciaranm> dberkholz: hot vs cold doesn't make much difference to the ratio either, since with hot cache you're doubling the syscall overhead
16:04 < ciaranm> dberkholz: numbers in seconds are "very small" to "double very small". it's when you multiply that by 10k it gets to be the problem.
16:04 <@lu_zero> using a default set like xorg + kde + gnome would be a good benchmark
16:04 <@dberkholz> in which situations will people be multiplying it by 10k?
16:05 < ciaranm> dberkholz: you do 10k metadata lookups to do a pretend-install world
16:05 <@lu_zero> even if the minimal set would be a portage or a system set
16:06 <@dberkholz> we've gotta wrap this up
16:06 <@dberkholz> next step is trying to get a portage implem & benchmarked
16:07 <@dberkholz> let's get that and go from there
16:07 <@dev-zero> but to make it clear: benchmark is not the main issue, it may just be another issue
16:08 <@dev-zero> s/benchmark/performance
16:08 <@lu_zero> dev-zero which is the other issue in your opinion?
16:08 <@leio-dl> I think I was supposed to bring my technical objection to G55 to list?
16:09 <@lu_zero> my main concern is least surprise/ease of use, then performance
16:09 < dleverton> The other issue is whether the prosposed solution is insane or not.
16:09 < ciaranm> the whole "having to open the ebuild" thing isn't even an issue if you stick with the EAPI= assignment restrictions i posted, since if you're ok to assume those restrictions you don't need to open the ebuild to check cache validity
16:09 <@dberkholz> i really need to go now
16:09 <@dev-zero> lu_zero: restrictions the various solutions imply
16:09 <@leio-dl> I'm not even sure what's being talked about here
16:10 <@dberkholz> should we close the meeting or is there another council member who wants to wrap up?
16:10 <@dev-zero> let's close the meeting