path: root/meeting-logs/20090312.txt

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