Add Council log and summary for meeting on December 11th, 2008

1 files changed, 169 insertions, 0 deletions

diff --git a/meeting-logs/20081211.txt b/meeting-logs/20081211.txt
new file mode 100644
index 0000000..a47cc6a
--- /dev/null
+++ b/meeting-logs/20081211.txt
@@ -0,0 +1,169 @@
+<11.12.2008 22:04> <@dberkholz> who's here?
+<11.12.2008 22:04>  * Halcy0n is
+<11.12.2008 22:04> <@dertobi123> <-
+<11.12.2008 22:04>  * lu_zero waves
+<11.12.2008 22:05> <@dberkholz> Cardoe: ?
+<11.12.2008 22:05>  * dev-zero is here as well
+<11.12.2008 22:07> <@dberkholz> Cardoe: council meeting starting, you might want to speak up soon
+<11.12.2008 22:07> <@dberkholz> let's get started
+<11.12.2008 22:07> <@Betelgeuse> yeah
+<11.12.2008 22:08> -!- dberkholz changed the topic of #gentoo-council to: Label profiles with EAPI for compatibility checks (revised)
+<11.12.2008 22:08> <@dberkholz> anyone not ready to vote?
+<11.12.2008 22:09> <@dberkholz> let's vote then
+<11.12.2008 22:09> <@dberkholz> yes from me
+<11.12.2008 22:09> <@dev-zero> second that
+<11.12.2008 22:09> <@lu_zero> ok from me
+<11.12.2008 22:09> <@dertobi123> yes, too
+<11.12.2008 22:09> <@Halcy0n> yes
+<11.12.2008 22:09> <@Betelgeuse> Do we want to say something about when it's allowed to start using later EAPis?
+<11.12.2008 22:10> < ciaranm> "whenever stable portage has had it for three months"?
+<11.12.2008 22:10> < ciaranm> strictly speaking, you can probably get away with it earlier. portage currently just allows everything it supports, and paludis merely warns for 0non-0 things in profiles...
+<11.12.2008 22:11> <@dberkholz> presumably we're only using it in new profiles, so we won't break existing ones
+<11.12.2008 22:11> <@Betelgeuse> dberkholz: But is that really useful? There's hardly any stuff in the end of the stack.
+<11.12.2008 22:11> <@Betelgeuse> Unless we want to start duplicating stuff.
+<11.12.2008 22:12> <@Betelgeuse> ciaranm: What about people installing from stages?
+<11.12.2008 22:12> <@Betelgeuse> ciaranm: But yeah for that we can just get away then.
+<11.12.2008 22:12> <@dberkholz> well, look at zac's email
+<11.12.2008 22:12> <@dev-zero> well, we could perhaps add a sanity check to "eselect profile" before switching profiles
+<11.12.2008 22:12> <@dberkholz>  For example, the base profile can remain at
+<11.12.2008 22:12> <@dberkholz> EAPI 0 and can thus be shared between some older profiles that
+<11.12.2008 22:12> <@dberkholz> conform to EAPI 0 (in all directories of the stack) and some newer
+<11.12.2008 22:12> <@dberkholz> profiles that contain some directories which require EAPI 1 or EAPI
+<11.12.2008 22:12> <@dberkholz> 2. By allowing a mixture of directories with different EAPIs, the
+<11.12.2008 22:12> <@dberkholz> intention is to promote code sharing such that it will be possible
+<11.12.2008 22:12> < ciaranm> Betelgeuse: they get a portage that allows EAPIs 0 and 1 in profiles anyway, so it doesn't really matter
+<11.12.2008 22:12> <@dberkholz> to use a common base profile between older and newer profiles, yet
+<11.12.2008 22:12> <@dberkholz> still be able to use new EAPIs in newer profiles.
+<11.12.2008 22:12> <@Betelgeuse> ah yeah multi parent sounds good to me
+<11.12.2008 22:13> <@Betelgeuse> We can put a version of Portage that supports the labeling to packages.
+<11.12.2008 22:14> <@dberkholz> it makes sense to me that profile EAPIs would be treated a lot like ebuild EAPIs, since we do have concepts of stable & dev profiles
+<11.12.2008 22:15> < ciaranm> Betelgeuse: don't even really need to. portage's current "anything it recognises" behaviour means this only starts to be an issue if we want to use EAPI 3 stuff in profiles, and by then i strongly suspect profile EAPIs will be a done thing
+<11.12.2008 22:15> <@dberkholz> anyway, it seems like zac's pretty well addressed your concern
+<11.12.2008 22:15> < ciaranm> 0 and 1 are supported in stages, and 2 doesn't add anything that makes sense in profiles
+<11.12.2008 22:15> <@Betelgeuse> ciaranm: but my scheme would work for paludis :D
+<11.12.2008 22:15> < ciaranm> paludis just moans noisily unless you set profile_eapi = 2 in the repo .conf file
+<11.12.2008 22:16> <@dberkholz> Betelgeuse: are you ready to move on, or do you have another concern?
+<11.12.2008 22:16> < ciaranm> and paludis users upgrade much more quickly than portage users, so assuming it's approved everyone using paludis will be using a profile_eapi supporting version within a week
+<11.12.2008 22:16> <@Betelgeuse> dberkholz: sure
+<11.12.2008 22:17> <@Betelgeuse> But let's say that a random dev should not go marking profiles EAPI 1
+<11.12.2008 22:17> <@Betelgeuse> Withour prior discussion on gentoo-dev.
+<11.12.2008 22:17> <@lu_zero> ok
+<11.12.2008 22:17> <@dev-zero> Betelgeuse: I don't think that's a problem
+<11.12.2008 22:20> <@dberkholz> dev-zero: do you want to explain why?
+<11.12.2008 22:20> <@dev-zero> ah, sorry. Well, I think that we all got enough training that people who really do change things in profiles know what they do
+<11.12.2008 22:21> <@Betelgeuse> dev-zero: Well I would think it to be quite easy to read the decision as allowed to use.
+<11.12.2008 22:21> <@dev-zero> Betelgeuse: that's true as well
+<11.12.2008 22:22> <@dberkholz> i don't think you can get away with adding higher eapi requirements to existing profiles.
+<11.12.2008 22:22> <@dev-zero> let's put it like that: non-dev-profiles need prior discussion
+<11.12.2008 22:22> <@dertobi123> i'd like to see the prior discussion on gentoo-dev, trained people tend to break things as well and some kind of review wouldn't hurt
+<11.12.2008 22:22> <@dberkholz> otherwise you're breaking users without giving them a clear path to fixing their setup
+<11.12.2008 22:23> <@dberkholz> say someone has an old portage version, they sync their tree, and suddenly their profile's busted and they can't do anything
+<11.12.2008 22:24> <@dberkholz> i think you can only add the eapi files to new or dev profiles
+<11.12.2008 22:25> <@Cardoe> I'm here.
+<11.12.2008 22:25> <@Cardoe> dang time change
+<11.12.2008 22:25> <@lu_zero> Cardoe still discussing the first item ^^
+<11.12.2008 22:26> <@dberkholz> Cardoe: i updated the google calendar last month, fyi
+<11.12.2008 22:26> <@dev-zero> dberkholz: agreed, otherwise you'll always have the possibility that someone ends up with a broken profile
+<11.12.2008 22:27> <@Cardoe> dberkholz: I don't use Google Cal
+<11.12.2008 22:27> <@Cardoe> I was at lunch with my wife and forgot I had to take an earlier lunch today due to the time change.
+<11.12.2008 22:28> <@dberkholz> Cardoe: to catch you up quickly, we're in favor of the profile eapis and are discussing when they are ok to add.
+<11.12.2008 22:28> <@Cardoe> I'm in support of labeling profiles with EAPI markers. However all current profiles need to be EAPI=0
+<11.12.2008 22:29> <@Cardoe> 2008.0 could potentially be EAPI=1
+<11.12.2008 22:29> <@Betelgeuse> s/8/9/
+<11.12.2008 22:30> < ciaranm> Cardoe: 1's safe now
+<11.12.2008 22:30> < ciaranm> Cardoe: 2 isn't, but there's nothing in 2 that's useful in profiles
+<11.12.2008 22:30> <@dberkholz> it seems like we always need to have some basic EAPI=0 profile around so that old users can upgrade to a newer portage
+<11.12.2008 22:30> <@Cardoe> ciaranm: exactly
+<11.12.2008 22:30> <@dberkholz> otherwise they sync and get stuck
+<11.12.2008 22:30> <@Cardoe> ciaranm: I can't see a reason for EAPI=2 appearing in profiles
+<11.12.2008 22:30> <@Cardoe> dberkholz: yeah the very base profile. I agree.
+<11.12.2008 22:31> <@dev-zero> dberkholz: or we get some kind of a pre-sync check
+<11.12.2008 22:31> <@Betelgeuse> dev-zero: how would that end to users?
+<11.12.2008 22:32> <@dev-zero> hmm, would probably only apply to a post eapi-2 era
+<11.12.2008 22:32> <@dberkholz> i don't see how that would work
+<11.12.2008 22:32> <@Betelgeuse> Can we vote on what we have now so that we can move on.
+<11.12.2008 22:33> <@dev-zero> jup
+<11.12.2008 22:33> <@Betelgeuse> Marker files => fine, Current profiles => EAPi 0, New profiles => higher.
+<11.12.2008 22:34> <@dberkholz> dev profiles higher too would be fine, i think
+<11.12.2008 22:34> <@Betelgeuse> sure
+<11.12.2008 22:34> <@Halcy0n> Sounds fine to me.
+<11.12.2008 22:35> <@dev-zero> sounds good
+<11.12.2008 22:35> <@dertobi123> sounds good to me
+<11.12.2008 22:35> <@dberkholz> good enough
+<11.12.2008 22:36> -!- dberkholz changed the topic of #gentoo-council to: EAPI change: Call ebuild functions from trusted working directory
+<11.12.2008 22:36> <@dberkholz> i don't really think it needs council approval to add something to EAPI=0 that exists in all the PMs, but i'm fine with rubber-stamping it
+<11.12.2008 22:37> <@Halcy0n> It has my approval
+<11.12.2008 22:37> <@dertobi123> second that
+<11.12.2008 22:37> <@lu_zero> +1
+<11.12.2008 22:37> <@Betelgeuse> ++
+<11.12.2008 22:37> <@dev-zero> ok from me
+<11.12.2008 22:39> -!- dberkholz changed the topic of #gentoo-council to: DEFINED_PHASES magic metadata variable
+<11.12.2008 22:40> <@dberkholz> anyone got an improvement for this?
+<11.12.2008 22:40> <@dberkholz> or other comment?
+<11.12.2008 22:40> <@Cardoe> hang on
+<11.12.2008 22:40> <@Halcy0n> No, it seemed fine to me.
+<11.12.2008 22:40> <@dberkholz> ciaranm: do you know whether there were any uses of USE-conditional functions in the tree?
+<11.12.2008 22:41> < ciaranm> dberkholz: there aren't
+<11.12.2008 22:41> <@dberkholz> excellent.
+<11.12.2008 22:41> <@Betelgeuse> I remember seeing some global scope use calls at some point.
+<11.12.2008 22:41> <@Cardoe> Well that covers question one..
+<11.12.2008 22:41> <@Betelgeuse> Don't remember specifics.
+<11.12.2008 22:41> < ciaranm> Betelgeuse: those *should* all have gone
+<11.12.2008 22:41> < ciaranm> unless they haven't...
+<11.12.2008 22:42> <@Cardoe> I think you mentioned it should optionally start to roll out into the cache, ciaranm.
+<11.12.2008 22:42> < ciaranm> Cardoe: yup
+<11.12.2008 22:42> <@Cardoe> Any reason why we shouldn't have infra regen the whole cache with that info?
+<11.12.2008 22:42> < ciaranm> well you could
+<11.12.2008 22:43> < ciaranm> it just isn't necessary
+<11.12.2008 22:43> <@Cardoe> I'm for it as well as just regenning the whole thing.
+<11.12.2008 22:43> <@Cardoe> Cause god only knows what packages might not be touched for a year or some such
+<11.12.2008 22:44> <@Halcy0n> Well, since the proposal says you shouldn't assume it is there for existing EAPIs, I don't see a reason to forcefully regen everything.
+<11.12.2008 22:44> < ciaranm> probably wouldn't hurt, if infra don't mind shutting off rsync updates for the six hours or whatever it is that it takes to do a regen
+<11.12.2008 22:44> <@Betelgeuse> ciaranm: find -name "*.ebuild" -exec egrep '^use' {} +
+<11.12.2008 22:44> <@Betelgeuse> ciaranm: Doesn't come out empty
+<11.12.2008 22:45> <@Betelgeuse> same false positives but at least one user in global scope
+<11.12.2008 22:45> < ciaranm> Betelgeuse: most of those look like they won't do what people expect anyway
+<11.12.2008 22:46> < ciaranm> and none of them seem to affect the proposal either
+<11.12.2008 22:46> <@dev-zero> open a tracker bug and give people two weeks time to fix those ebuilds?
+<11.12.2008 22:47> <@Cardoe> I could fix those right now if the power would come back on at home...
+<11.12.2008 22:47> < ciaranm> dev-zero: well, the proposal won't affect any of those anyway
+<11.12.2008 22:47> <@lu_zero> dev-zero if the number if small enough
+<11.12.2008 22:47> <@Betelgeuse> ciaranm: They are probably leftovers from when Portage did not preserve env properly.
+<11.12.2008 22:47> < ciaranm> so really it's just something that should get fixed because it's horrible, not something that has to be fixed before the phases cache can go ahead
+<11.12.2008 22:48> <@Cardoe> ciaranm's right.
+<11.12.2008 22:49> <@Halcy0n> So, is everyone ready to vote on it?
+<11.12.2008 22:50> <@dberkholz> i am
+<11.12.2008 22:50> <@dev-zero> yes
+<11.12.2008 22:50> <@dertobi123> yes and yes
+<11.12.2008 22:50> <@Betelgeuse> yes
+<11.12.2008 22:51> <@Halcy0n> Alright, so vote for it.  I'm in favor of it.
+<11.12.2008 22:51> <@dev-zero> me too
+<11.12.2008 22:51> <@dberkholz> yep
+<11.12.2008 22:51> <@dertobi123> so, yes again
+<11.12.2008 22:51> <@Cardoe> yep
+<11.12.2008 22:51> <@Betelgeuse> fine
+<11.12.2008 22:52> <@Halcy0n> Alright, that should be it then, right Donnie?
+<11.12.2008 22:52> <@Cardoe> ciaranm: you wanna open a bug for infra to turn that on?
+<11.12.2008 22:52> < ciaranm> Cardoe: gotta wait until portage has support first
+<11.12.2008 22:52> < ciaranm> then i think it's automatic
+<11.12.2008 22:53> <@lu_zero> sounds good
+<11.12.2008 22:55> <@dberkholz> i checked beforehand to make sure zac had said he sounded ok with this on that src_fetch_extra bug
+<11.12.2008 22:56> <@dberkholz> let's wrap it up, then.
+<11.12.2008 22:57> <@Halcy0n> Cya later guys, I have to go.  Thanks Donnie.
+<11.12.2008 22:57> <@dertobi123> when's the next meeting? i think we could drop the 25th?
+<11.12.2008 22:57> <@dev-zero> sorry, just a sec
+<11.12.2008 22:57> <@dberkholz> next week if we have bugs open. because of xmas, as we decided last month
+<11.12.2008 22:57> <@dev-zero> got some questions
+<11.12.2008 22:58> <@dev-zero> is the council page going to be updated?
+<11.12.2008 22:58> <@dberkholz> i'll take care of getting things updated tonight
+<11.12.2008 22:58> <@dev-zero> does somebody mind if we're going to write down the new voting rules?
+<11.12.2008 22:58> <@dberkholz> now that we have some actual news to send out
+<11.12.2008 22:59> <@dev-zero> I'm asking because I still didn't see any decision whether the council might consist of only 1,2,3 people in case _reopen_nominations is ranked that high
+<11.12.2008 22:59> <@dev-zero> and I'd rather like to have that cleared before the next elections
+<11.12.2008 22:59> <@dberkholz> we still need to have that discussion
+<11.12.2008 23:00> <@dberkholz> we're out of time for today, though. feel free to propose it for the next meeting in response to the announcement
+<11.12.2008 23:00> <@dev-zero> good, can we discuss it on the council-ml until next meeting?
+<11.12.2008 23:00> <@dberkholz> yep
+<11.12.2008 23:00> <@dev-zero> good
+<11.12.2008 23:00> < ciaranm> http://dpaste.com/98260/ <-- not really in danger of becoming an issue for a while
+<11.12.2008 23:01> <@dberkholz> meeting is over, for anyone who's been waiting for that.