path: root/meeting-logs/20080925.txt

20:00 < darksiide > ding!
20:00 <Betelgeuse@> 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 <Betelgeuse@> dberkholz: \o/
20:03 <dertobi123@> <- 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 <Betelgeuse@> dberkholz: Shouldn't you have his number :D
20:06 <Betelgeuse@> 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 <Betelgeuse@> 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 <Betelgeuse@> So we would move a copy like that to the PMS project pages then?
20:10 <Betelgeuse@> 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 <dertobi123@> 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 <Betelgeuse@> ciaranm: Well pms-2 would isntall the tag
20:15 <      dang+> Good question...
20:15 <Betelgeuse@> 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 <Betelgeuse@> 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 <dertobi123@> indeed
20:17 <      dang+> Fine with me.
20:17 <Betelgeuse@> 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 <Betelgeuse@> 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 <Betelgeuse@> ciaranm: council approval for changes
20:18 <Betelgeuse@> 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 <Betelgeuse@> +1
20:20 <     jokey@> ++
20:21 < dberkholz@> who agrees with the tag?
20:21 <   Halcy0n@> Please tag it :)
20:22 <Betelgeuse@> 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 <Betelgeuse@> cache changes should be needed because of tree wide changes which should go through us
20:26 <   Halcy0n@> Fine by me.
20:26 <Betelgeuse@> not always of course
20:27 <Betelgeuse@> 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 <Betelgeuse@> 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 <dertobi123@> yep
20:36  *    jokey notes a bunch of stuff falls into that category actually
20:36 <      dang+> Sure.
20:36 <Betelgeuse@> the majority has spoken
20:37 <Betelgeuse@> 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 <dertobi123@> i'm unsure, so it wouldn't hurt to approve it. i'm for it :)
20:44 <Betelgeuse@> 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 <Betelgeuse@> 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 <Betelgeuse@> +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 <Betelgeuse@> 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 <Betelgeuse@> ciaranm: Hmm. True.
20:58 <Betelgeuse@> 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 <Betelgeuse@> remi`: You shouldn't commit something you haven't tested so after a pkg manager is committed with support for it
20:58 <Betelgeuse@> 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 <Betelgeuse@> 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 <jmbsvicett > council: thanks for approving EAPI-2
21:03 <   zmedico > thanks for approving the PROPERTIES stuff too