path: root/meeting-logs/20080710.txt

20:01 < dberkholz@> looks like lu just got kicked offline
20:01 <     jokey@> yep
20:02 <     jokey@> he should really use screen ;)
20:02 < Flameeyes@> jokey: or quassel :P
20:02 <dertobi123@> screen ftw.
20:03 < dberkholz@> ok. one more time, agenda for the meeting is here: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
20:03 -!- Irssi: #gentoo-council: Total of 53 nicks [6 ops, 0 halfops, 0 voices, 47 normal]
20:03 <Betelgeuse@> Flameeyes: some kind of backgrounding IRC client?
20:03 < Flameeyes@> Betelgeuse: yeah it's a (core+client) client
20:03 < dberkholz@> who's here: Betelgeuse , Flameeyes , jokey , dertobi123 
20:03 < Flameeyes@> I am
20:03 < dberkholz@> and me
20:03 <   Halcy0n@> Me
20:03 < dberkholz@> Halcy0n, lu need to speak up (and show up again in lu's case)
20:03 < dberkholz@> ah, there you are
20:04 <     jokey@> hi lu_zero
20:05 <dertobi123@> luca!
20:05 <    fmccor > You might op him  :)
20:05 <     jokey@> he can do that himself ;)
20:05 < dberkholz@> lu_zero: back for good?
20:06 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
20:06 <   lu_zero@> sigh
20:06 <   lu_zero@> let the damn thing sync
20:06 <   lu_zero@> and I will
20:06 <   lu_zero@> ok
20:08 < dberkholz@> ok, everyone's here now
20:08 < dberkholz@> sorry for the lag
20:08 < dberkholz@> first topic is glep 54
20:10 < dberkholz@> anyone got anything to say?
20:10 <     jokey@> short statement for the logs? ;)
20:11 <     jokey@> doesn't look like it
20:11 <Betelgeuse@> dberkholz: Well as older Portage versions don't handle it correctly, it can't yet be used in the tree so what's the use of making it official?
20:11 <   lu_zero@> I don't feel the glep changed any way
20:11 < Flameeyes@> I still haven't heard anything that moves me from my original position of not liking it
20:12 <Betelgeuse@> dberkholz: glep 55 should be handled before 54
20:12 < dberkholz@> Betelgeuse: your reasoning, please?
20:12 <Betelgeuse@> dberkholz: 23:11 <@Betelgeuse> dberkholz: Well as older Portage versions don't handle it correctly, it can't yet be used in the tree so what's the use of making it official?
20:12 <Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
20:13 <Betelgeuse@> dberkholz: and older Portage versions work just fine
20:13 <   lu_zero@> glep 55 -> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
20:13 < dberkholz@> glep 54 claims backwards compat is quite reasonable
20:13 < dberkholz@> "Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary version suffixes and die during various tasks making portage hard or impossible to use. Later versions just ignore them displaying warnings. Hence use of scm suffixes in gentoo-x86 tree will probably have to wait till 2008.0 release or later."
20:13 < Flameeyes@> so let's say virtual/eapi-migration-method
20:14 < Flameeyes@> [so glep55 or something providing the same interface]
20:14 <   lu_zero@> dberkholz problem: if you have -scm installed
20:14 <   lu_zero@> and then switch to a pm not knowing it
20:14 <   lu_zero@> you have a nice recipe for inconsistency
20:14 <Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0
20:15 <Betelgeuse@> although zmedico seems to be doing it every once in a while
20:15  *  lu_zero in general opposes having non-definitions
20:15 <      igli > if it doesn't break anything.. ;)
20:16 <   Halcy0n@> I would really like to see a list of features that we would end up having after implementing this GLEP.  The GLEP mentions possible enhancements, but I'd like to see what we would have planned if we go forward with this change.
20:16 <   Halcy0n@> Well, it only mentions one enhancement, I'd like to see what else we could do to judge if it is worth it.
20:16 <   lu_zero@> Halcy0n that had been requested
20:16 < Flameeyes@> Halcy0n: that was my concern in the first place
20:16 <   lu_zero@> the feedback hadn't be that helpful
20:16 < dberkholz@> (fyi, i'm writing down the exact questions we have for posting to the list afterwards)
20:17 <   Halcy0n@> Okay, I'm still catching up with everything that has gone on, so ignore me if I repeat something that happened already :)
20:17 <Betelgeuse@> Halcy0n: Adding global scope functions.
20:17 <Betelgeuse@> Halcy0n: But that can also be done by cleaning profile bashrcs and adding stubs
20:17 < Flameeyes@> Betelgeuse: I _think_ Halcy0n was referred to 54
20:17 < dberkholz@> are we on 55 or 54 here? we seem to be bouncing around
20:17 <   Halcy0n@> I thought we were discussing 54.
20:17 <     jokey@> 54
20:17 <   antarus > 54
20:17 < Flameeyes@> 42
20:18 < Flameeyes@> [sorry couldn't help it]
20:18 <   antarus > Flameeyes: hike!
20:18 <   antarus > Flameeyes: also good to see you here ;)
20:18 <Betelgeuse@> Halcy0n: periodit reinstalls
20:18 <   lu_zero@> Betelgeuse I wasn't aware the package manager has cron capabilities...
20:19 <Betelgeuse@> lu_zero: lol
20:19 -!- lu_zero changed the topic of #gentoo-council to: glep 54 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
20:19 <   Halcy0n@> Betelgeuse: yes, I know there are some things we could do, but I'd like to see a more extensive list of possibilities, what are other possible ways of doing this (like a metadata tag for the ebuild), and why those other methods aren't sufficient.
20:21 <   lu_zero@> Halcy0n I started to write down alternatives with features that interest me in http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
20:22 < dberkholz@> i think the point here is that the glep should address what made its implementation superior to other possible ones, which it also describes
20:22 <   Halcy0n@> Do we all agree that we should wait to make a decision on this until we have a list of actual features, and why its the best solution?
20:22 <     jokey@> (and make sure that it is the best option)
20:22 <     jokey@> ++
20:23 < Flameeyes@> agreed again
20:23 <dertobi123@> Halcy0n: agreed
20:23 <   lu_zero@> agreed
20:23 <Betelgeuse@> Halcy0n: We can wait any way as it can't be used in the main tree.
20:24 <   antarus > s/can't/should not be/
20:24 <   antarus > but I'm a pedant
20:24 < dberkholz@> ok, i've noted the issues raised here
20:25 < dberkholz@> once they're address, the glep can be revised and we'll consider it again
20:25 < dberkholz@> addressed*
20:25 < dberkholz@> let's move on to glep 55
20:25 -!- lu_zero changed the topic of #gentoo-council to: glep 55 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
20:26 < dberkholz@> who likes it?
20:27  *    jokey doesn't, solves a non-existant problem
20:27  *  lu_zero doesn't solves a non-existant problem in an unclean fashion
20:27 <   lu_zero@> missing coma
20:27  *  lu_zero doesn't, solves a non-existant problem in an unclean fashion
20:27 <   Halcy0n@> Not I, same reason.
20:28 < Flameeyes@> ibid.
20:28 <     jokey@> maybe we should just vote
20:28 <gentoofan2 > what about the reasons mentioned in the glep?
20:28 < dberkholz@> 4 of us just said they don't like it because it solves a nonexistent problem
20:28 <   antarus > I disagree with your wording
20:28 <   antarus > it certainly solves a problem
20:28 <dertobi123@> dberkholz: agreed on that, make it 5
20:28 <Betelgeuse@> I agree with antarus
20:29 <   antarus > the problem is not a blocker for Gentoo
20:29 <   antarus > (to my knowledge)
20:29 < dberkholz@> is it a problem for gentoo in any fashion at all? are there any other features we want that depend on it? if so, i haven't seen a glep for 'em
20:29 <Betelgeuse@> But I don't see the use of accepting it before we a) Portage has something that would make use of it b) some other pkg manager is made official
20:30 <   Halcy0n@> antarus: I can agree with that wording as well. :)  I think we were implying it wasn't a problem for Gentoo when we were saying it solved a non-existant problem.
20:30 <   antarus > I imagine the kde and java people have odd ideas rolling around
20:30 <   lu_zero@> Alternatives anyway -> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
20:30 <   Halcy0n@> So, can we vote on postponing a GLEP of this nature until another glep requires such changes?
20:31 <Betelgeuse@> Halcy0n: agreed
20:31 <gentoofan2 > Halcy0n: like glep 54?
20:33 <     jokey@> gentoofan23: nah, we want more input on that glep... 55 we just want to defer until we need something like that
20:33 <   Halcy0n@> gentoofan23: you could say that, yes.  If we want to introduce features, and actually have features that need these changes, then I'm all for it.
20:33 <   Halcy0n@> Just changing things for the sake of changing them though...
20:33 <dertobi123@> jokey: until we have a pÃroblem this glep would solve, yeah
20:34 <     jokey@> dertobi123: yep, :)
20:34 < dberkholz@> like one implementation of the overall idea in glep 54
20:34 < dberkholz@> since we just decided we want to hear about why that is better than the other ones, 55 may or may not be required
20:34 <   Halcy0n@> Flameeyes: lu_zero, dberkholz:  do you agree with postponing 55 as well?
20:34 < Flameeyes@> I do
20:34 <   lu_zero@> Halcy0n 55 or any other migration paths
20:35 <   lu_zero@> I don't like the one proposed in glep55
20:35 <   lu_zero@> and I think there are nicer alternatives
20:35 <Betelgeuse@> dberkholz: the implementation is called paludis
20:36 < dberkholz@> Betelgeuse: i'm not talking about a PM that implements that feature. i'm talking about whether -scm is the best way to solve the problem.
20:36 <gentoofan2 > dberkholz: you mean like a repo using said features?
20:36 <     jokey@> no, the way the problem is solved
20:36 <  DrEeevil > I still say a tag in the ebuild (like RESTRICT) is all you need
20:37 <     jokey@> dberkholz: so we deferred this until we have use?
20:38 < dberkholz@> so, glep 54 in its current state is likely to depend on either glep 55 or some other eapi bump to allow -scm
20:38 <   lu_zero@> DrEeevil please expand the reasoning in ml
20:39 <  DrEeevil > lu_zero: ok
20:40 < dberkholz@> looks like this is postponed at least till we've got a solid 54 
20:40 <     jokey@> okay
20:40 <     jokey@> next topic then?
20:40 <   lu_zero@> jokey yup
20:40 < dberkholz@> glep 56
20:41 -!- jokey changed the topic of #gentoo-council to: glep 56 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
20:41 < Flameeyes@> dberkholz: for the logs, I don't see any change in the reasoning for discussing the two of these again since last time -- we might want to decide to not discuss them again until there's a need for them]
20:42 <   Halcy0n@> Cardoe posted some updates to the GLEP a little while ago, did everyone have a chance to look at them?
20:42 < dberkholz@> Flameeyes: 54 & 55, you mean?
20:42 < Flameeyes@> dberkholz: yes
20:43 < dberkholz@> i like 56's current backwards compat section
20:43 < Flameeyes@> Halcy0n: have you the link handy of the exact changes?
20:43 <   Halcy0n@> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2  is the diff
20:43 < Flameeyes@> thanks
20:44 <     jokey@> glep is good from my pov
20:44 <   Halcy0n@> I like this one
20:45 <     jokey@> anyone having questions about it?
20:45 <   lu_zero@> got pointed that useflag definitions should be bound to a matching atom
20:45 < Flameeyes@> good for me [well was good for me before too]
20:46 <   lu_zero@> and that is yet not completely crystal clear (even if present)
20:46 <dertobi123@> i also like it, but in the last paragraph of backwards compatibility it is unclear to me what "approving" the glep has to do with auto-generation of use.local.desc
20:46 <   Halcy0n@> lu_zero: I believe that's the restrict attribute?
20:46 < dberkholz@> dertobi123: by moving local flags to metadata.xml, instead of duplicating information in two places that gets out of sync we want to autogenerate the old location for legacy tools
20:46 <    Cardoe > sorry all.. I mentally overslept.
20:47 <dertobi123@> dberkholz: might make more sense to change the wording from "approved" to "fully implemented" or "implemented for local use-flags" then?
20:47 <   lu_zero@> Halcy0n as I said, it is a nit
20:48 < dberkholz@> i don't even see that it's a nit. it looks already addressed to me
20:49 <     jokey@> indeed
20:49 <    Cardoe > Well the first step of making that portion happen is going to be to add a check to repoman that if use.local.desc is not present in the repo, do new QA check.
20:49 <    Cardoe > Once that's in place that developers can use, then the infra script will happen.
20:50 <    Cardoe > I've already discussed it with the Portage folks and the infra folks.
20:50 <jmbsvicett > Cardoe: Won't devs require updated validation tools?
20:50 <   lu_zero@> good
20:50 <    Cardoe > jmbsvicetto: right. which is why we're going to update repoman first.
20:50 <   Halcy0n@> I am for approving this one.
20:50 < dberkholz@> dertobi123: i guess my reading is a little different .. was reading the "will work to remove" part as implementing
20:50 <jmbsvicett > Cardoe: ok
20:51 <     jokey@> Halcy0n: make it more formal and "request for vote" :)
20:52 < dberkholz@> ok, let's vote: approve glep 56, yes or now
20:52 < dberkholz@> no*
20:52 <     jokey@> yes
20:52 <   Halcy0n@> yes
20:52 < dberkholz@> yes
20:52 <dertobi123@> dberkholz: the "will work to remove" part works for me as implementing, too
20:52 <Betelgeuse@> \o/
20:52 <dertobi123@> so, yes
20:52 < Flameeyes@> yes
20:52 < dberkholz@> wb Betelgeuse =)
20:53 <Betelgeuse@> windzor: wherw was I?
20:53 <     jokey@> okay, glep accepted :)
20:53 <Betelgeuse@> s/windzor/dberkholz/
20:53 < dberkholz@> i dunno, not talking during the 56 discussion. figured you were elsewhere
20:53 < dberkholz@> that's all the agenda topics. two more quick things i wanted to mention
20:54 < dberkholz@> 1 -- we're moving to biweekly meetings, so the next one will be july 24
20:54 < dberkholz@> 2 -- we are actively discussing the appeals and will get decisions out asap
20:55 <jmbsvicett > dberkholz: Where do you plan to announce the decisions?
20:56 <     jokey@> dev-announce and council imho
20:56 <   lu_zero@> agreed
20:56 <     jokey@> dunno though ;)
20:56 < dberkholz@> via private email to them, certainly. not sure exactly where on the public side yet
20:58 <jmbsvicett > Can you please update the topic here and or make a note on the council ml when you decide where to make the annoucement?
20:58 < dberkholz@> sure
20:58 <   lu_zero@> dberkholz summary link?
20:58 -!- jokey changed the topic of #gentoo-council to: Next council session july 24 || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
20:58 <     jokey@> actually...
20:58 < dberkholz@> lu_zero: i'll post it later this evening
20:58 <   lu_zero@> ok
20:58 -!- jokey changed the topic of #gentoo-council to: Next council session july 24
20:59 < Flameeyes@> dberkholz: is the meeting still open? [mostly because I have to run]
20:59 < dberkholz@> we're done for today
20:59 <   lu_zero@> btw my vote for 56 is yes ^^
20:59 <   antarus > dberkholz: well run meeting; thanks all
20:59 < Flameeyes@> sorry guys, I run away then :) have a nice weekend all of you :P