20:00 < darksiide > ding! 20:00 dong 20:00 < ciaranm > the witch is dead 20:02 < dberkholz@> who's here? 20:02 < dberkholz@> lost track of time for a sec 20:03 dberkholz: \o/ 20:03 <- here 20:03 * Halcy0n is here 20:03 < jokey@> plop 20:03 < dang > <- is Cardoe today 20:03 < jokey@> dang: oh, reincarnation? ;) 20:03 < dang > jokey: More like astral projection... 20:04 < dberkholz@> where's lu? 20:04 -!- jokey changed the topic of #gentoo-council to: Next meeting: now 20:06 < dberkholz@> ok, let's get started without him 20:06 < dberkholz@> can someone try to contact him somehow? 20:06 -!- mode/#gentoo-council [+v dang] by Halcy0n 20:06 < dberkholz@> (and speak up so i know who you are) 20:06 dberkholz: Shouldn't you have his number :D 20:06 I can dig it out too of course. 20:06 < dberkholz@> it would be nice for someone else to step up and do something occasionally.. 20:07 < dberkholz@> here's a brief agenda -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt 20:08 < dberkholz@> so let's get rolling on eapi-2 20:08 < dberkholz@> anyone not ready to vote? 20:08 dberkholz: txt msg sent 20:08 < Halcy0n@> I am ready. 20:08 -!- thargor__ is now known as thargor 20:08 < dberkholz@> as i mentioned before the meeting, i stuck a pdf at http://dev.gentoo.org/~dberkholz/pms/pms_eapi-2_no-kdebuild-1_20080925.pdf -- see the appendix 20:09 So we would move a copy like that to the PMS project pages then? 20:10 Or the html output generated for better linking from stuff like devmanual would work too. 20:10 < dberkholz@> i'd like to just stick a tag in git 20:10 < dang+> An html copy somewhere would be *really* nice. 20:10 < jokey@> dberkholz++ 20:11 < jokey@> one of us should just add a gpg signed one there and be done with it 20:11 < dberkholz@> putting a copy in the pms project space would make sense to me, so people have somewhere simple to get this info 20:11 < dberkholz@> any pms folks can comment on that? 20:11 < ciaranm > app-doc/pms 20:11 < dang+> That's what I meant, of course. The official one could still be in git. 20:11 < jokey@> maybe add a generated one to the project page as well so people don't need to install texlive just to take a look at it 20:12 jokey: pdf and html (as dang suggested) would be nice, yeah 20:12 < ciaranm > ferdy: ^^ you can do that, right? 20:13 < dang+> and an app-doc/pms-2 for people who do want a local copy. 20:13 < nirbheek > app-doc/pms-bin? :) 20:13 < dang+> Heh. 20:13 < ciaranm > dang: i was just going to merge the eapi-2 branch into master... 20:14 < ciaranm > the only reason eapi 2 is on a branch just now is to avoid giving the impression it's been finalised 20:14 < jokey@> anyway, nothing else required for vote, right? ;) 20:14 < dang+> ciaranm: Sure, I have no problem with that. 20:14 < dang+> But cutting a tarball, sticking it on the mirror, and having a pms-2 version in portage would be a nice touch. 20:14 < dang+> Not required, but nice. 20:15 < ciaranm > do we do a new tarball when we write some more of the EAPI 0 stuff, then? 20:15 ciaranm: Well pms-2 would isntall the tag 20:15 < dang+> Good question... 20:15 ciaranm: if coming from git 20:15 < dang+> tag may be better, I'd forgotten about that. :P 20:15 < ciaranm > a tag doesn't really make sense to me 20:16 < ciaranm > i mean, what'd it tag? the first eapi 2 commit? the last eapi 2 commit? the most recent eapi 2 related fix? the most recent fix that is some way relevant to eapi 2? and once it's there it's stuck 20:16 ciaranm: For EAPI 0 of course not, but we aren't approving that atm. 20:16 < Halcy0n@> So, can we vote? The specifics of what we do with PMS can be discussed separately. 20:17 indeed 20:17 < dang+> Fine with me. 20:17 ciaranm: Well we can tie the ebuild to particular commits too. 20:17 < Halcy0n@> So, yes from me. 20:18 * Sput thinks people mean a branch rather than a tag 20:18 ciaranm: And increase it as fixes come I guess. 20:18 < ciaranm > Betelgeuse: so how's that different from just pointing the ebuild at master? 20:18 ciaranm: council approval for changes 20:18 ciaranm: if wanted 20:18 < dberkholz@> if we approve one thing, the wording could later change so that it actually means something else 20:19 * jokey is for it too 20:19 < ciaranm > in which case the conflict resolution process kicks in 20:19 < dang+> But a signed tag specifying what was actually the state at approval time would help a lot... 20:20 < dang+> Just as a historical record, if nothing else. 20:20 < dang+> Anyway, I vote to approve, too. 20:20 < dberkholz@> i would like to see a tag that says something like eapi-$EAPI-approved-$DATE 20:20 * jokey got a note that lu went to bed already 20:20 < ciaranm > it would? *shrug* sign and tag away all you like. tags are cheap. 20:20 < dberkholz@> but yes, i am also for eapi 2 20:20 * dertobi1 is too 20:20 +1 20:20 < jokey@> ++ 20:21 < dberkholz@> who agrees with the tag? 20:21 < Halcy0n@> Please tag it :) 20:22 I do 20:22 < dberkholz@> (btw, just to make it clear for the record, EAPI=2 is approved.) 20:22 * dertobi1 agrees 20:22 * jokey too 20:22 * dang too 20:23 < ciaranm > ok, someone please make a signed tag then and mail it to the list which doesn't exist yet 20:23 < dberkholz@> is it merged to master already? 20:23 < dang+> Heh. 20:23 < ciaranm > is now! 20:24 < dberkholz@> updated agenda/summary -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt 20:24 < dberkholz@> please verify the EAPI=2 section 20:25 < Halcy0n@> Sounds good to me Donnie. 20:25 < dberkholz@> ok, let's move on to the next topic 20:25 < dberkholz@> PROPERTIES in cache 20:26 < jokey@> no need to approve cache changes imho as long as they don't break older versions of portage 20:26 < dberkholz@> there were zero objections on-list 20:26 * dang agreed with jokey 20:26 * dertobi1 too 20:26 < dberkholz@> yeah, that's my feeling 20:26 cache changes should be needed because of tree wide changes which should go through us 20:26 < Halcy0n@> Fine by me. 20:26 not always of course 20:27 So why not do both? 20:27 < zmedico > the cache is a community asset 20:27 < dberkholz@> cache changes aren't just needed because of changes to the tree, but because portage is just tracking more data 20:27 < zmedico > so I don't really think it's all my decision 20:28 < dberkholz@> that's why i think the ebuild PROPERTIES section is more relevant to us directly, because that part always impacts the tree 20:28 < ciaranm > cache is an EAPI / PMS thing, and all sorts of third party apps rely upon it, so changing it isn't something to be done without proper discussion 20:28 < zmedico > nod 20:29 The council hasn't had that much technical stuff to decide any way so I don't see why we would need to cut down the list. 20:30 < jokey@> ciaranm: that's why I added "as long as it doesn't break older stuff" 20:30 < jokey@> if one just adds fields, it shouldn't be a real issue anywhere 20:30 < dberkholz@> you can only cut down the list if something was on the list to start with ... cache changes have never gone through council in the past to my knowledge 20:30 < ciaranm > that's not entirely true... 20:30 < zmedico > note that there is currently an upper limit on the number of cache entries 20:31 < zmedico > 22 max, 7 unused 20:31 < zmedico > adding PROPERTIES leaves 6 unused 20:31 < ciaranm > you can use things that are currently defined as unused without breaking things. you can't *add* without breaking portage 20:31 < ciaranm > dberkholz: the last cache change was pre-council, wasn't it? 20:32 < dberkholz@> i don't think so 20:32 < ciaranm > wasn't the last cache change the addition of the EAPI field? 20:32 < zmedico > last addition was EAPI 20:32 < zmedico > few years back 20:34 < dberkholz@> seems like if anything, this should be another issue that PM devs resolve amongst themselves and only present to council if they can't agree 20:34 < dberkholz@> is there a lack of agreement? 20:35 < ciaranm > there's no disagreement on PROPERTIES, just some of the proposed values for it 20:35 < dberkholz@> ok 20:36 < dberkholz@> do council people agree with what i said? 20:36 < jokey@> sure 20:36 yep 20:36 * jokey notes a bunch of stuff falls into that category actually 20:36 < dang+> Sure. 20:36 the majority has spoken 20:37 So let's go with that then. 20:37 < jokey@> right 20:37 < dberkholz@> ok, if you guys agree on PROPERTIES in cache, go for it. 20:37 * ciaranm shall add it to pms 20:38 < dberkholz@> let's move on to the PROPERTIES=interactive 20:39 < remi` > quick question: PROPERTIES is added to which EAPI ? 20:40 < ciaranm > remi`: PROPERTIES is retroactively added to 0, 1 and 2 with the restriction that it can't be used for anything that package managers can't safely ignore 20:40 < remi` > great, thanks for the clarification 20:41 < Halcy0n@> Are there any disagreements on having PROPERTIES=interactive from any of the PM people? 20:41 < ciaranm > interactive was the one we didn't disagree on 20:41 < dberkholz@> i'm presuming zmedico agrees with it too =) 20:42 < zmedico > nod 20:42 < dberkholz@> council members, do you think this is something that should require council approval? 20:44 < Halcy0n@> I think it makes sense for us to approve it. 20:44 i'm unsure, so it wouldn't hurt to approve it. i'm for it :) 20:44 yes 20:44 < jokey@> yes 20:44 < jokey@> ;) 20:44 < dberkholz@> to generalize, new global variables in ebuilds that are used by the PM 20:45 < dang+> Probably a good idea. 20:45 < jokey@> anything global imho 20:45 < jokey@> so it expands to vars and functions 20:45 < ciaranm > vars and functions would be an EAPI thing anyway 20:46 < dberkholz@> unless they're optional again 20:46 < dberkholz@> seems like an odd use case though 20:46 < dberkholz@> pkg_pretend() anyone? 20:46 < jokey@> eapi stuff 20:47 < jokey@> so handled within pms group as usual 20:47 < ciaranm > pkg_pretend is a lot easier if you can be sure it'll get used... so it's a lot easier as an EAPI thing... 20:47 < dberkholz@> reasonable 20:48 < dberkholz@> what we're saying is that new ebuild features that aren't covered by PMS/EAPIs still need to be approved by the council 20:49 < jokey@> eh, isn't all this global ebuild stuff (to be) covered by pms? 20:49 < ciaranm > there aren't going to be many things done that way, so it's probably easier to just send every new EAPI and every carefully done retroactive EAPI change to the council... 20:50 indeed 20:50 < jokey@> ++ 20:50 < dberkholz@> ciaranm: so you're classifying this as a retroactive EAPI change? 20:51 < dberkholz@> i'm a bit underslept lately 20:51 < ciaranm > dberkholz: PROPERTIES? yeah 20:51 < ciaranm > PROPERTIES is an EAPI thing that we just happen to be able to get away with doing retroactively by carefully weasel wording it 20:51 < dberkholz@> yeah, ok, that way we can just say it's just a standard pms/eapi thing and not deal with setting new policies and whatnot 20:52 < dberkholz@> so let's move on to the approval vote 20:52 < Halcy0n@> How are we determining which properties are allowed though? Is that tied to a particular EAPI at this point, or are you wording it up in such a way that new ones can be introduced at any time? 20:53 < dberkholz@> since PROPERTIES handling is optional, i was assuming that support for any given value of it was also optional 20:53 < Halcy0n@> I just wanted to make sure :) 20:53 < dberkholz@> and any new value would require council approval the way we've said it 20:53 < ciaranm > what dberkholz said 20:53 < Halcy0n@> Okay, thanks. 20:54 < Halcy0n@> I vote to approve it. 20:54 < dberkholz@> so do i 20:54 +1 20:54 < dang+> ++ 20:55 < dberkholz@> ok, that's our agenda for today 20:55 < dberkholz@> and right on time too! 20:55 < Sput > nice work *clap* 20:55 < Halcy0n@> Awesome. Thanks for getting everything organized Donnie. 20:55 < dberkholz@> less so every week, as i get less and less sleep... 20:55 < dberkholz@> adios, gotta run! 20:56 < jokey@> ++ 20:56 I can make the tag. 20:56 * jokey thinks donnie should get some choclate and cookies for free 20:56 < ciaranm > Betelgeuse: do you know how to mail tags for git? i've never had to done that 20:57 * dertobi1 hands donnie some swiss chocolate i bought in zurich yesterday :) 20:57 < maekke > dertobi123: =) 20:57 ciaranm: Hmm. True. 20:58 ciaranm: I can try the normal way. 20:58 < remi` > oh, I had one tiny question : when can we start using EAPI=2 in ~ and/or stable ebuilds ? 20:58 remi`: You shouldn't commit something you haven't tested so after a pkg manager is committed with support for it 20:58 remi`: zmedico probably does a release today 20:58 < remi` > Betelgeuse, of course, but once portage is out, we can start using it? 20:59 < ciaranm > paludis will probably be tomorrow, unless my laptop speeds up... 20:59 remi`: yes 20:59 < Caster > remi`: and in stable ebuilds when a portage that supports it is stable, I guess 21:00 < ciaranm > zmedico / anyone else: please review the properties branch i just committed to pms 21:00 < zmedico > sure 21:01 < remi` > Betelgeuse, Caster, ok thanks 21:02 council: thanks for approving EAPI-2 21:03 < zmedico > thanks for approving the PROPERTIES stuff too