path: root/meeting-logs/20101130.txt

[22:00:48] <wired> alrighty, it's meeting time
[22:00:58] <Chainsaw> Roll call!
[22:01:08] <wired> ^^
[22:01:17] <Chainsaw> Chainsaw is here.
[22:01:33] <wired> Betelgeuse, Chainsaw, ferringb, jmbsvicetto, scarabeus <--- ping
[22:01:40] <Chainsaw> pong!
[22:01:53] <ferringb> gnip
[22:02:03] <jmbsvicetto> pong
[22:03:25] <Chainsaw> Do we have phone numbers for Betelgeuse & scarabeus?
[22:03:25] <wired> I guess Mark didn't assign a proxy for today?
[22:03:47] <jmbsvicetto> I have both
[22:03:59] * wired calling thomas
[22:04:26] *** Quits: Tommy[D] (~TommyD]@gentoo/developer/tommy) (Remote host closed the connection)
[22:04:29] <jmbsvicetto> Betelgeuse joined 5 minutes ago, so he should be around
[22:04:44] <scarabeus> blaghr
[22:04:44] <wired> i actually invited him, so it could be an auto-accept
[22:04:47] <scarabeus> thnaks
[22:04:50] <scarabeus> for cal
[22:04:52] <wired> heheh
[22:04:53] <wired> yw
[22:05:10] *** Joins: Tommy[D] (~TommyD]@gentoo/developer/tommy)
[22:05:21] <jmbsvicetto> wired: hmm, ok
[22:05:25] <jmbsvicetto> I'll call him then
[22:05:32] <wired> okie
[22:06:48] <Betelgeuse> hmm
[22:06:52] <jmbsvicetto> ^^
[22:07:07] <Betelgeuse> Didn't have an alarm reminder
[22:07:08] <wired> great
[22:07:11] <Betelgeuse> sorry for being late
[22:07:25] <wired> no worries
[22:07:38] <Chainsaw> Is that everyone? :)
[22:07:44] <wired> yeap
[22:07:47] <wired> agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_7890bad79264c057cbf503fbd0f6e5d8.xml
[22:07:55] *** wired changes topic to 'Next meeting: Now | http://archives.gentoo.org/gentoo-dev-announce/msg_7890bad79264c057cbf503fbd0f6e5d8.xml'
[22:08:06] <wired> I'd like us to start with the last item
[22:08:27] <Chainsaw> Okay; can't do Friday/Saturday/Sunday. All other days fine.
[22:08:34] <Chainsaw> (Any time of day)
[22:08:36] <wired> ok
[22:08:38] *** Quits: alexxy (~alexxy@gentoo/developer/alexxy) (Remote host closed the connection)
[22:08:55] <wired> so is everyone ok with my proposed Tuesday/Saturday plan?
[22:09:24] <wired> One tuesday for Tony, one saturday for Mark?
[22:09:34] <Chainsaw> wired: Saturday I can possibly do if I know far in advance; past 1pm UTC.
[22:09:45] <Chainsaw> wired: Friday or Sunday are definitely out.
[22:10:21] <Chainsaw> It's not convenient, but I don't want to ruin it for others.
[22:10:24] * ferringb notes we really need to find something that is friendlier to usian times if at all possible
[22:10:31] <jmbsvicetto> I'm fine with it
[22:10:37] <wired> oh Saturday 1300 UTC would be perfect
[22:10:39] <Betelgeuse> ferringb: I don't consider this time overlay friendly either
[22:10:42] <ferringb> fortunately, I aparently have no sane schedule so I'm reasonably flexible, but halcyon, not so much
[22:10:43] <Chainsaw> ferringb: This is fairly friendly to US time already.
[22:10:54] <Chainsaw> ferringb: Note that it is 8pm at night, in a dark office with only the light above my desk on.
[22:11:15] <jmbsvicetto> wired: Saturday 1300 UTC is 0600 PDT, iirc
[22:11:18] <ferringb> well, 1300 UTC is 5am my time
[22:11:46] <jmbsvicetto> right
[22:11:46] <ferringb> and halcy0n would be 3-5am for that
[22:12:01] <wired> jmbsvicetto: yes but Mark said its good for him
[22:12:26] <jmbsvicetto> we currently have people spreading a 10 hour time span, iirc
[22:12:38] <wired> Weekend: 0700-1300 UTC-5, 1900-0000 UTC-5
[22:12:41] <wired> ^^ thats what mark said
[22:13:11] <ferringb> UTC -5, not UTC
[22:13:39] <ferringb> atlantic/east coast times, basically
[22:13:45] <jmbsvicetto> Betelgeuse: you're currently UTC+2, no?
[22:13:46] <wired> yes, 0800 UTC-5 is 1300 UTC, right?
[22:14:03] <Betelgeuse> jmbsvicetto: yes
[22:14:22] <Chainsaw> I can do 1pm and later, as required.
[22:14:52] <wired> ferringb: is that time acceptable for you at all?
[22:15:46] <jmbsvicetto> ferringb: up until what time would you be available on Friday and from what time on Saturday?
[22:17:00] <ferringb> sorry, interuptions
[22:17:39] <ferringb> either it needs a +5 to it, or -2
[22:18:02] * ferringb can swing it if needed for a couple of meetings, but 5am is not exactly a time I'm good at being conscious
[22:18:55] <ferringb> just run with it for the time being
[22:19:01] <wired> okay
[22:19:05] <jmbsvicetto> ferringb: so up until what time would you be willing to stay up on Friday and from what time are willing to be awake on Saturday?
[22:19:49] <ferringb> my times; 10->00 UTC-08 generally speaking
[22:20:11] <ferringb> I can veer out of that within limits (I already have meetings on european time as is)
[22:21:16] <wired> you think you could handle a 07 UTC-08?
[22:21:42] <ferringb> sundays would be better for it, but yes.
[22:21:49] <wired> or a 08
[22:21:59] <ferringb> basically; if I'm the one with the weird time, I'll swing what I have to.
[22:22:28] <wired> ok so guys, 1500 UTC Saturday, is that good for (just) our next meeting?
[22:22:31] *** Joins: alexxy[home] (~alexxy@gentoo/developer/alexxy)
[22:22:38] <Chainsaw> wired: I'll make that work, yes.
[22:23:09] <ferringb> fine by me, but I strongly suggest you double check that with mark to make sure y'all are converting correctly (and that he intentionally aimed for 3-4am EST time)
[22:23:33] * ferringb hates timezones on a related note
[22:23:51] <wired> he could have made a mistake, we'll talk briefly on the alias
[22:24:18] <wired> ok, thank you. I'll take everyone else's silence as a yes
[22:24:56] <scarabeus> yep
[22:25:08] <wired> lets move on to EAPI 4
[22:26:15] <wired> in last meeting it was proposed (by few_) to finalize EAPI-4 now, in the state that's currently implemented in portage
[22:26:23] <wired> zmedico: ping
[22:26:39] <zmedico> wired: pong
[22:26:43] *** Joins: Philantrop (~Philantro@exherbo/developer/philantrop)
[22:26:45] <wired> there's a draft of EAPI-4 here: http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4_pre1
[22:27:24] <wired> zmedico: everything in eapi-4_pre1 is implemented, right?
[22:27:26] <Chainsaw> I will repeat my objection;  REPLACING_VERSIONS & REPLACED_BY need clear examples.
[22:27:36] <jmbsvicetto> ferringb: Any comments / concerns from your part about the above?
[22:27:39] <zmedico> wired: right
[22:27:43] <Chainsaw> Based on that document, it is not clear what the package manager expects of me in my ebuild.
[22:28:44] <wired> Chainsaw: I understand those variables as helpers for you, not something you have to use
[22:28:48] <Chainsaw> (And that worries me, because "shall" suggests I can't omit it)
[22:29:00] <Betelgeuse> Chainsaw: The final approval is a PMS commit any way
[22:29:08] * Chainsaw reads "shall" as defined in an RFC
[22:29:13] <Betelgeuse> Chainsaw: So for drafting that text we can make it clearer
[22:29:15] <Chainsaw> Which is "you MUST do this".
[22:29:28] <ferringb> jmbsvicetto: controllable compression and symlinks for docs mostly
[22:29:43] <Chainsaw> i.e. You MUST use these two variables that I have not described very well here.
[22:29:45] <ferringb> jmbsvicetto: few others, but honestly, test ebuilds/pkgs are needed to really smoke out how well it works
[22:29:56] <Chainsaw> Everything else looks very good though.
[22:30:13] <wired> Chainsaw: I think shall here means "will be defined and available in these stages"
[22:30:27] *** Quits: pchrist (~spirit@gentoo/developer/pchrist) (Quit: leaving)
[22:30:32] <Chainsaw> wired: Please clarify that in some way or use a different word.
[22:31:07] *** Joins: pchrist (~spirit@gentoo/developer/pchrist)
[22:31:33] <wired> ok
[22:31:36] <Chainsaw> wired: "shall be defined". "Helmets shall be worn" "Children shall be accompanied by an adult at all times". Nothing about is optional.
[22:31:43] <wired> so we all have minor issues with the documentation
[22:31:56] *** Quits: pchrist (~spirit@gentoo/developer/pchrist) (Client Quit)
[22:32:01] <wired> do we all agree that the implemented featureset is good enough for a new eapi?
[22:32:07] <ferringb> zmedico: what ebuilds out there exist using eapi4 for testing btw?
[22:32:23] <ferringb> wired: yeah, hold up
[22:32:27] * ferringb would like that question answered
[22:32:35] <zmedico> ferringb: none that I know of
[22:32:57] <ferringb> wired: I have no real issues with what's there doc wise
[22:33:12] <Chainsaw> ferringb: You can't write ebuilds until you finalise the documentation.
[22:33:15] <Chainsaw> ferringb: That seems a bit unfair.
[22:33:20] <ferringb> Chainsaw: can too :P
[22:33:26] * ferringb isn't asking for gentoo-x86 converted over
[22:33:32] *** Joins: pchrist (~spirit@gentoo/developer/pchrist)
[22:33:37] <jmbsvicetto> I may have misunderstood the purpose of the example for pkg_pretend. If I didn't, I'm worried as in my reading it seems we may be creating some issues for binary packages
[22:33:38] <ferringb> sanity checking mainly
[22:34:19] <Betelgeuse> wired: yes it's enough
[22:34:31] <jmbsvicetto> we could ask for volunteers to test the spec in an overlay
[22:34:35] <ferringb> either way, that's my only real concern
[22:35:20] <Chainsaw> I'm happy with the feature set, and will vote "yes, with REPLACING_VERSION/REPLACED_BY_VERSION *not* mandatory".
[22:35:22] * ferringb defers to the others however for their collective opinion
[22:36:01] <jmbsvicetto> wired: This seems enough to create EAPI-4
[22:36:17] <ferringb> Chainsaw: reason for not wanting it mandatory?
[22:36:22] <wired> jmbsvicetto: yes, thats what I think as well
[22:36:37] <jmbsvicetto> ferringb: can it be mandatory and empty?
[22:36:49] <Chainsaw> ferringb: Because it is for all intents & purposes undocumented and the need is not apparent to me.
[22:37:08] <jmbsvicetto> I need to re-read their purpose
[22:37:23] <ferringb> Chainsaw: it's a corner case thing where it's useful
[22:37:35] <wired> my understanding is those variables are useful if you need to perform specific actions when replacing specific versions
[22:37:49] <ferringb> Chainsaw: documentation arguement I won't disagree with, it needs specifics, but it's purpose I strongly agree with
[22:37:58] *** Quits: Tommy[D] (~TommyD]@gentoo/developer/tommy) (Remote host closed the connection)
[22:38:06] <jmbsvicetto> can anyone address my concern about the use of pkg_pretend on binary packages? Mainly about the docs suggesting you could some "kernel checks"
[22:38:15] <Chainsaw> ferringb: Without clear documentation it is not clear what I am voting in.
[22:38:28] <ferringb> jmbsvicetto: pkg_pretend has known issues
[22:38:37] *** Joins: Tommy[D] (~TommyD]@gentoo/developer/tommy)
[22:38:37] <Betelgeuse> wired: it's useful to detect upgrade vs. reinstall etc too
[22:38:40] <Chainsaw> ferringb: "Chainsaw, you said yes to this 3 months ago."
[22:38:55] <ferringb> Chainsaw: well, you did.  I have logs :P
[22:38:58] <Chainsaw> ferringb: If you want me to say yes, show me examples. How do I use it, why can't I omit it.
[22:38:59] <Betelgeuse> wired: no need to show those "if you are upgrading" messages all the time
[22:38:59] * ferringb groks
[22:39:06] <wired> Betelgeuse: yeah, indeed
[22:39:08] <ulm> Chainsaw: maybe this is good enough for REPLACING_VERSION/REPLACED_BY_VERSION: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob;f=ebuild-env-vars.tex;h=f96b2038a5ac7f3d5aaf767159e53fae924797e4;hb=HEAD
[22:39:30] <Chainsaw> ulm: Do you have that in english please?
[22:39:59] <ulm> Chainsaw: what?
[22:40:20] <Chainsaw> \toenail &&
[22:40:25] <zmedico> jmbsvicetto: just substitute "kernel checks" with "random checks that can be done earlier than pkg_setup, before deps are installed"
[22:40:26] <Chainsaw> / (1) 23)
[22:40:29] <Chainsaw> Hard to read.
[22:40:49] <scarabeus> Chainsaw: REPLACED_VERSIONS= packages that i uninstall in order to have this package installed so lets say 7.0:0 8.1:1
[22:40:49] <scarabeus> REPLACED_BY_VERSION= packages that removes me
[22:41:01] <jmbsvicetto> zmedico: ok. It's just that to me that seems to be suggesting some actions that will break for binary packages
[22:41:03] <scarabeus> s/packages that/package thatr/
[22:41:14] <jmbsvicetto> zmedico: or better put, for people using a central build box
[22:41:37] <ulm> Chainsaw: voila: http://dev.gentoo.org/~ulm/pms.pdf
[22:41:48] <zmedico> jmbsvicetto: basically, it has similar caveats as pkg_setup checks
[22:41:55] <Chainsaw> ulm: That I can read, thank you.
[22:42:17] <ulm> Chainsaw: page 51
[22:42:19] <ferringb> ulm: is there a specific statement of what the value will be?
[22:42:23] <zmedico> jmbsvicetto: it allows to give earlier feedback to the user, that's all
[22:42:24] <ferringb> specifically an atom, or
[22:42:33] <ferringb> ah, versions.
[22:43:16] <ferringb> ulm: zmedico: not quiet sure I see the purpose in "versions", instead of 'version' (plural vs singular) there
[22:44:03] <Chainsaw> ulm: Text still reads as awkward to me, but yes, I can vote that in.
[22:45:06] <ulm> Chainsaw: they are also described in the table on page 49
[22:45:13] <ulm> maybe it's clearer there
[22:45:25] <jmbsvicetto> ulm: thanks for the link
[22:45:32] <zmedico> ferringb: yeah, portage never puts more than one version there as it is
[22:45:32] <jmbsvicetto> so the variable can be defined as empty
[22:45:46] <jmbsvicetto> Chainsaw: so if you don't have a need to use it, just define it as empty
[22:46:07] <zmedico> ferringb: it's always 1 package per slot
[22:46:15] * ferringb nods, hence my point ;)
[22:46:40] <Chainsaw> Has been clarified privately by leio, I'm happy to vote in EAPI 4 as is.
[22:46:53] <ferringb> ulm: was the use specification w/in PMS updated to ensure no trailing -/+ for use dep defaults btw?
[22:46:58] <wired> excellent
[22:47:25] <ferringb> if not, should be.  it's a minor naggle, but cross the t's, dot the i's, etc
[22:47:42] <ulm> ferringb: I have to check
[22:48:10] <ferringb> minus that naggle (which I presume no one has an issue if the spec is tweaked to cover it after the fact), I'm +1
[22:48:22] <wired> jmbsvicetto: are your pkg_pretend concerns settled?
[22:48:54] <Chainsaw> ferringb: Some sentences need rewriting, that is acceptable.
[22:49:31] * ferringb still would like a var jammed into eapi to indicate if installing from source build or binary
[22:49:37] <ferringb> having such a thing would address jmbsvicetto's concern.
[22:49:50] <jmbsvicetto> wired: I see they're the same as the exiting ones for pkg_setup
[22:50:07] *** Quits: ABCD (~abcd@gentoo/developer/abcd) (Ping timeout: 252 seconds)
[22:50:08] <ferringb> jmbsvicetto: reduced via REQUIRED_USE also
[22:50:29] <jmbsvicetto> wired: so instead of getting it fixed on the spec, we'll have to club ^W teach people about it ;)
[22:50:34] <wired> jmbsvicetto: well in the end it's up to the devs to use it properly
[22:50:37] <wired> yeah
[22:50:59] <ulm> ferringb: USE flag syntax must be updated in PMS still, but that's a minor issue really
[22:51:04] <wired> zmedico: would the var ferringb asked be hard to implement?
[22:51:07] *** Joins: ABCD (~abcd@gentoo/developer/abcd)
[22:51:16] <ferringb> wired: it's basically there already, it's just not standardized
[22:51:23] <ferringb> it's 5 minutes in any manager
[22:51:51] <zmedico> wired: implemented already: http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4_pre1-metadata-required-use
[22:52:18] <ferringb> zmedico: he's asking about a "we're installing from a binary" var
[22:52:34] <zmedico> oh, that's easy
[22:52:47] <zmedico> there's already EMERGE_FROM=binary
[22:53:00] <ferringb> name sucks
[22:53:00] <zmedico> can add another var like that
[22:53:10] <wired> yeah, sounds easy too, so if it could be included in EAPI-4 it'd be nice
[22:53:22] <ferringb> ulm: comments?
[22:53:55] *** Quits: alexxy[home] (~alexxy@gentoo/developer/alexxy) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
[22:53:56] <Chainsaw> Flushing a boiler out for ~2 minutes. My vote on EAPI 4 is yes. Back soon.
[22:54:07] <ferringb> -.^
[22:54:12] <ulm> ferringb: EMERGE_FROM sucks indeed as a name
[22:54:14] <jmbsvicetto> ferringb: I don't use it myself, but infra and people with large deployments might not be happy to have an ebuild fail to merge because someone wants to die on a certain kernel version or config when the package is built on a build server
[22:54:26] <ferringb> jmbsvicetto: aware, but they already run into it
[22:54:31] <jmbsvicetto> sure
[22:54:36] <ferringb> jmbsvicetto: and a certain luddite dev has an override for that last I knew
[22:55:23] <ferringb> ulm: MERGING_FROM perhaps?
[22:55:45] <ferringb> specifically with two potential values; source, binary
[22:56:06] * wired likes that better
[22:56:10] <Betelgeuse> how about we flesh that out for EAPI 5
[22:56:20] <Betelgeuse> and just make it happen in a reasonable timetable
[22:56:26] <scarabeus> so MERGE_TYPE=[ 'binary', 'source' ]
[22:56:32] <scarabeus> ah alread brian offered something :)
[22:57:01] <wired> Betelgeuse: this is so minor we could just let them implement it after we pass EAPI-4 imo
[22:57:20] <ferringb> Betelgeuse: just mentioning it now since we've been talking about this sort of var for a long while, and it *does* address the pkg_pretend/pkg_setup concerns
[22:57:27] <Chainsaw> Back.
[22:57:30] <ferringb> plus frankly, ebuild devs already are doing shit like this if you go looking ;)
[22:57:46] *** Joins: alexxy[home] (~alexxy@gentoo/developer/alexxy)
[22:58:50] <ferringb> how about this
[22:59:16] <ferringb> if we all agree on eapi4, and we agree said var is needed... wording gets sorted in the next few days via email, and the puppy is stamped at that point.
[22:59:25] <ferringb> if we all agree on 4, but not the var, well, you all suck
[22:59:33] <ferringb> but we move on and discuss it in eapi5 timelines
[22:59:40] <ferringb> that work for folks?
[22:59:50] <wired> MERGING_FROM is good enough for me to accept it now
[22:59:58] <jmbsvicetto> works for me
[23:00:14] <ferringb> same for me, but I'd like to keep the option of tweaking it if absolutely needed for paludis needs
[23:00:18] <jmbsvicetto> besides, the official stamp is put on a PMS tag / patch
[23:00:24] * ferringb notes they're not represented here, primarily
[23:00:34] <scarabeus> also with eapi4 stabilisation i have this idea of qa policy update, how about we would require use of latest eapi possible instead of least possible as is now since that would require new devs to be really in common only in few eapis also we are now having quite few ones so even i have to use cheatsheet to see what i can do :D
[23:00:53] <jmbsvicetto> I hope that var can help fix current issues with binary packages
[23:00:58] <ferringb> scarabeus: seperate discussion... and a very very heated one I'd expect
[23:01:03] <wired> indeed
[23:01:07] <ferringb> scarabeus: ml is the starting point for that imo
[23:01:10] <wired> scarabeus: this should start on the ML
[23:01:13] <scarabeus> ok
[23:01:24] <wired> ok 
[23:01:32] <jmbsvicetto> scarabeus: we should probably start a discussion about "deprecating" EAPIs too ;)
[23:01:51] <wired> lets do an official vote about EAPI-4 approval then
[23:02:04] <Betelgeuse> scarabeus: that's already accepted practise
[23:02:11] <Betelgeuse> wired: there's nothing to vote on
[23:02:11] <Chainsaw> wired: EAPI-4 with additional vars discussed: YES
[23:02:19] <jmbsvicetto> scarabeus: oldest / newest debate is interesting, but as Patrick as been talking for a long time, we should think about limiting the number of EAPIs active at each point in time
[23:02:32] <wired> Betelgeuse: i know, just for the record
[23:02:43] <scarabeus> Betelgeuse: nope, accepted and qa enforced practise is to use oldest eapi around
[23:02:47] <jmbsvicetto> wired: let's rephrase it
[23:02:57] <Betelgeuse> scarabeus: weird, never seen that
[23:03:03] <scarabeus> Betelgeuse: (with features your ebuild needs)
[23:03:18] <jmbsvicetto> let's vote on asking PMS team to provide a patch to implement EAPI-4 with the linked spec and the discussed vars?
[23:03:51] <ferringb> jmbsvicetto: that's a +1 from me.  I want that var, but if folks don't, I'm still +1 on eapi-4.
[23:03:57] <jmbsvicetto> Betelgeuse: when PMS was approved, everyone was told to use the oldest EAPI that was good enough for the ebuild
[23:03:59] <scarabeus> +1 from  me
[23:04:04] <Chainsaw> Flushing boiler out second time; have 2 minutes to decide what we're voting on please.
[23:04:15] <scarabeus> :D
[23:04:20] <wired> jmbsvicetto: i don't think eapi4 needs to go through council again, we already have the specs
[23:04:35] <Betelgeuse> jmbsvicetto: PMS as a whole has never been approved
[23:05:03] * ferringb cracks the whip... voting?
[23:05:08] <ferringb> still have .la
[23:05:17] <wired> jmbsvicetto: I'd just approve eapi4 and give the respective portage/docs team the go to implement them
[23:05:17] <Betelgeuse> I vote that I can vote when the commit to tag is ready.
[23:05:27] <jmbsvicetto> Betelgeuse: yeah, sorry. I meant when EAPI-1 was approved
[23:05:49] <jmbsvicetto> wired: as Betelgeuse as said, we can only vote on the tag
[23:06:05] <ferringb> anyone have issues doing that via email?
[23:06:19] <jmbsvicetto> That's why I'm suggesting we agree to vote on asking PMS team / any volunteers on writing the patch to get the EAPI-4 tag
[23:06:32] <wired> ferringb: whatever makes it happen faster
[23:06:46] <ferringb> that's basically my views
[23:06:51] <Betelgeuse> email is fine
[23:06:56] <wired> ok lets sum up.
[23:06:58] * Chainsaw returns
[23:07:03] <Chainsaw> So gents, what are we voting on?
[23:07:14] <ferringb> Chainsaw: getting me my damn pony.
[23:07:53] <wired> we agree we want a tag ready for eapi-4, including the extra var, so we can vote on it, by email or on a meeting (depending on the timing)
[23:08:25] <jmbsvicetto> Do we want to task anyone (a council member) on getting this done?
[23:08:44] <jmbsvicetto> bah, I missed a ? on (a council member?)
[23:09:12] <ferringb> jmbsvicetto: unless ulm disagrees, I'd punt the req to him
[23:09:25] *** Joins: hwoarang (~hwoarang@gentoo/developer/hwoarang)
[23:09:25] <ferringb> non-council I realize, but logical choice
[23:09:28] <ferringb> ulm: you mind?
[23:09:46] <jmbsvicetto> ferringb: seems a good idea to me
[23:11:40] <wired> ulm seems afk...
[23:11:50] <wired> lets give him some time while we talk about la files
[23:12:00] <ulm> yeah, fine with me
[23:12:05] <Chainsaw> ulm agrees!
[23:12:05] <wired> ah great :)
[23:12:07] <wired> :D
[23:12:12] <ferringb> ulm: sweet.  now you have to write that patch ;)
[23:12:13] <Chainsaw> Well I'm glad that's sorted :)
[23:12:20] <wired> excellent news
[23:12:30] <wired> seems we're gonna have eapi-4 in 2010 after all :)
[23:12:45] <jmbsvicetto> ulm: Thanks
[23:12:50] <wired> ulm: thanks indeed
[23:12:52] <ferringb> ulm: yeah, danke.
[23:12:57] <ulm> np
[23:13:00] * Chainsaw bows politely to ulm
[23:13:08] <Chainsaw> wired: So, what else do you have on the agenda for today?
[23:13:10] * ferringb needs to duck out for 5-10 minutes.  continue about your ways .la wise, will be back shortly
[23:13:12] <wired> la files
[23:13:20] <wired> last item
[23:13:22] <wired> jmbsvicetto: your floor
[23:13:33] <jmbsvicetto> wired: I'm sorry but I dropped the ball on this one :\
[23:13:44] <jmbsvicetto> So, what's the status:
[23:13:55] <Chainsaw> (Back in 2 minutes, will read scrollback)
[23:14:28] <jmbsvicetto> 1. we need to write a doc, we can use Diego's blog post as sources - he agreed to license them under CC-SA and add it to the QA space - assuming there's no objection from the QA team
[23:14:50] <jmbsvicetto> 2. then we need to publish the news item referencing the doc
[23:14:59] <jmbsvicetto> 3. get the new portage version stable
[23:15:23] <jmbsvicetto> zmedico: how soon can we get it?
[23:15:51] <jmbsvicetto> 4. we can let ebuild devs remove la files as required
[23:16:13] <wired> most recent 2.1.9 was committed 3 days ago
[23:16:14] <jmbsvicetto> Is there anyone interested in helping out with 1?
[23:16:56] <jmbsvicetto> wired: we don't need the most recent. iirc, the first usable version should be almost 4 weeks now
[23:17:37] <wired> the first one still in tree is *portage-2.1.9.24 (31 Oct 2010)
[23:17:38] <jmbsvicetto> but as I've said before, I don't think we need to wait the 30 days for this
[23:17:51] <jmbsvicetto> so 1 month
[23:18:12] <wired> but .25 seems to have some important fixes
[23:18:35] <jmbsvicetto> unless anyone wants to volunteer for 1, I think we can and should take this for the mls
[23:18:53] <ago> jmbsvicetto: I have not read the backlog, the documentation on what is it?
[23:19:00] <jmbsvicetto> ssuominen: I'm sorry for not getting it sorted out by now
[23:19:24] <ago> i'm just passing through :P
[23:19:48] <wired> ago: la file removal
[23:20:38] <wired> jmbsvicetto: well, lets push it to the ML then and hope we get more replies than last time
[23:21:43] <wired> I have many things on my shoulders now, but I'll do my best to find some time to help as well
[23:22:21] <Betelgeuse> I need to finish for today.
[23:22:26] <Betelgeuse> Early start tomorrow.
[23:22:35] <jmbsvicetto> wired: so are we done for today?
[23:22:37] <wired> i think we're done
[23:22:48] <jmbsvicetto> wired: Thanks for chairing today's meeting
[23:22:54] <wired> thank you all for being here
[23:23:15] *** Quits: alexxy[home] (~alexxy@gentoo/developer/alexxy) (Read error: Connection reset by peer)
[23:23:22] <jmbsvicetto> wired: I can chair next meeting
[23:23:29] <jmbsvicetto> wired: can you recall me the date?
[23:23:42] <wired> yeah, hold on
[23:24:18] <wired> Saturday, 18th of December, 1500 UTC
[23:25:15] <Chainsaw> Thanks wired :)
[23:26:10] <jmbsvicetto> wired: you may want to call the end of the meeting - for log's sake ;)
[23:26:36] <wired> ---- meeting end ----