It is attached, the log&summary has already been put on the project
page.

-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

Roll Call:
===========
Betelgeuse: here
Cardoe: here
dberkholz: here
dertobi123: here
dev-zero: here
leio: here
lu_zero: absent(?, waiting for feedback), 37 minutes late
tanderson(secretary): here

Topics:
===========

EAPI-3 Proposals:

    Note: The following two proposals were discussed before it was realized
    that there was not sufficient time to discuss all of them. At that point a
    call for objections to any of the proposals found at [1] was asked for,
    and none were made. A full list of proposals for EAPI 3 follow.

    - New phase: pkg_pretend
        This phase is most useful for displaying conflicting USE flags at
        dependency resolution time(pretend), though it has various other uses
        so that errors about installing the package can be displayed before
        installation of packages begin.

        Conclusion:
            Approved for the draft.

    - [flag(+/-)] USE dependencies
        This may be needed when one wishes to depend on a package with a
        certain USE flag but if the USE flag is not present in that package
        assume it is on or off(+ and - respectively).

        Conclusion:
            Approved for the draft.

    - Multislot Dependency Specifications
        This allows ebuils to tell the package manager that runtime
        dependencies are not swappable(:1 installed at runtime can't be
        removed even though :2 'satisfies' the dependency).

    - PROPERTIES mandatory in cache
        Some information provided by this variable is useful at --pretend
        time(interactive packages). 

    - DEFINED_PHASES mandatory in cache
        Same reasons as for PROPERTIES, but is also useful for determining
        the phases a package provides with just the cache.

    - Provide a default src_install prototype.
        Get rid of the need for the src_install functions with just `emake
        install` in them. Some discussion is needed to clear up issues with a
        DOCS variable for extra documentation and a list of docs to
        automatically get installed.

    - Provide a `docompress` function.
        This function serves as a replacement for prepalldocs. `docompress`
        can optionally compress files in /usr/share/doc according to a set of
        inclusion and exclusion lists.

    - Provide a '-r' option to `dodoc`
        Providing a way to put `dodoc` in recursive mode is widely accepted.

    - Make `doins` preserve symlinks
        This obsoletes the `cp -R` constructs frequently seen and is easy to
        implement.

    - Limit values in $USE to those in $IUSE.
        Certain USE_EXPAND flags may be in USE even if they aren't
        specifically set in IUSE. Eliminate this.

    Next Action:
        The Council agreed to have portage implement as many of these as
        possible in a month and then make that EAPI 3.

Technical Agenda Items:

    - GLEP 54
        Thomas(tanderson) sent out a comparison of GLEP 54 and the liveebuild proposals.
        Among those discussing GLEP 54 there was a general consensus that
        there was nothing wrong with it as a first step to get correct
        ordering. Luca(lu_zero) commented that all he was concerned about was
        that there was not enough 'meat' to the GLEP.

        Next Action:
            Doug(Cardoe) and Luca(lu_zero) intend to write a
            GLEP to handle the second part of the problem(making the revision
            available to ebuilds/package manager/users.

    - GLEP 55
        Petteri, Zac, and Ciaran were supposed to benchmark the various
        proposals and report back. Zac did not write the code for portage so
        Petteri had nothing to report on this issue. Ciaran commented that
        the solutions other than GLEP 55 had a 50% slowdown in the valid cache
        situation compared to GLEP55, but did not post the raw numbers or the
	    patches used.

        Next Action:
            Zac needs to benchmark the proposals in portage.

Open Floor:
===========

- Migration of KEYWORDS from ebuilds to profiles:
  Ned Ludd(solar) brought this up, but it came up in the middle of agenda
  items so was not talked about much. Some points were made that such a scheme
  would require a git conversion, but nothing was agreed upon. 


References:
[1]: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ

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@...:pms-bugs@g.o
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