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=fe...@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=arkan...@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.mccre...@googlemail.com:pms-b...@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=tob...@alpha.libexec.de] 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=tob...@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=didko...@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=to...@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=to...@212.247.117.70] 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

Attachment: pgpKC0HkruFZ5.pgp
Description: PGP signature

Reply via email to