21:00:09 Mon Dec 7 19:00:03 UTC 2009 21:00:10 Calchan: ping? 21:00:13 * robbat2|na is here is for any questions/issues with his gleps 21:00:32 Betelgeuse, pong 21:01:02 Calchan: your show 21:01:12 robbat2|na, great, sorry for the screwup, I do too many things at the same and didn't see you were requesting that for january only 21:01:21 Betelgeuse, yes I was on -dev with grobian 21:01:29 so who's here? 21:01:36 I'm here, but see my e-mail 21:01:40 i only said january as IIRC they had to be posted a month in advanced 21:01:42 Calchan: can you please add a link to the agenda to topic 21:02:20 --> NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council 21:02:23 --- Calchan has changed the topic to: http://archives.gentoo.org/gentoo-council/msg_55e2123621095cba53e2fe4d700bfb76.xml 21:02:29 thx 21:02:54 Betelgeuse, note that there's a couple changes in the htread 21:03:04 Calchan: yes I read the thread 21:03:07 solar said he would very probably not be here 21:03:16 and we have his votes by email 21:03:22 Calchan: but best to ahve something for the audience 21:03:22 in case we want to use them 21:03:57 Calchan: He preferred post votes so he can see leading discussion and I think we should do that 21:03:58 * dertobi123 yawns 21:04:14 Betelgeuse, let's vote 21:04:18 later 21:04:35 ulm, lu_zero ping 21:04:40 here 21:04:46 ok 21:05:25 so we seem to have: Betelgeuse, leio, ulm, dertobi123 and Calchan 21:05:47 you guys want to wait for lu_zero a bit more or assume he won't be showing up? 21:06:16 Calchan: The agenda had 5 minutes so go with that 21:06:29 ok, who's logging? 21:06:31 I am 21:06:32 There's no votes due before point 3 any way 21:06:35 Calchan: I do 21:06:42 * ulm does too 21:06:43 and who wants to chair? 21:07:02 as I wrote I can do it if you prefer 21:07:22 Calchan: You did a good job with the agenda so if you don't mind 21:07:28 ok 21:07:31 and thanks 21:07:42 1.4 remarks on the agenda 21:07:58 let's move the many GLEPs discussion to open floor, do you agree? 21:08:05 fine 21:08:06 yes 21:08:09 i've already sent remarks in my e-mail reply 21:08:29 dertobi123? 21:08:30 my work meeting got cancled. So looks like I can be here. 21:08:36 solar, yay 21:08:40 Calchan? 21:09:02 dertobi123, are you ok with moving the glep discussion to open florr and not voting for this meeting? 21:09:07 sure 21:09:11 solar, too? 21:09:20 guess that was already decided on list 21:09:25 ok then 21:09:40 do we skip the vote by email discussion as solar is here? 21:09:43 I have no objections to glep-58 moving fwd as it causes no impact to anybody 21:09:44 I'd say yes 21:10:01 yes better suited for discussion by email for example 21:10:43 --- Calchan gives voice to zmedico 21:11:02 ok, let's switch to 2 EAPI3 status 21:11:16 zmedico, you said ETA in roughly 3 months 21:11:36 in your mail, could you elaborate or was it a very rough guess? 21:12:45 while we're waiting for zac, what do you guys think of doing an EAPI bump with what's already done? 21:12:50 tbh lets remove those eapi-3 status updates from this and the upcoming agendas. it's done when it's done. it doesn't help nor speeds up the process to discuss this again and again 21:12:54 --> Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council 21:13:09 Calchan: It only makes sense if there's something valuable already done. 21:13:23 Calchan: No reason for having a new one if devs have no need for it. 21:13:25 Calchan: I don't see any use for that, maybe except for prefix 21:13:32 dertobi123, I was actually going to ask zmedico how we could help him and his team 21:13:41 Calchan: vim *.py 21:13:52 s/vim/${EDITOR/ 21:14:51 so the general opinion is that there's nothing worth yet to justify a pre-3 EAPI bump? 21:15:44 anybody? 21:15:56 the things done are mainly removing deprecated stuff and cleanups 21:16:15 new (and old) devs have to learn additional stuff for every additional EAPI 21:16:27 i don't think it's helpful to split up eapi-3 now 21:16:28 so we should keep their number limited 21:16:32 Calchan: None of the main EAPI 3 features are done. 21:16:36 ulm: agreed 21:17:00 ok, then if nobody has anything to add let's leave it a tthis and switch to prefix 21:17:12 and we're almost on time 21:17:25 what advantage is it to make others wait on feautres when they are ready? 21:17:52 solar: There's nothing in the tracker that would make a big difference for devs 21:18:37 --- Calchan gives voice to grobian 21:18:50 solar, ok to switch to 3. prefix? 21:19:29 looks like it 21:19:52 so, have you guys reviewed the material posted by the prefix team in response to our requests? 21:20:12 I mean the answers to our questions, the PMS patch and the portage stuff 21:20:12 yes, and looks good to me 21:20:47 Calchan: I havent' seen a pms patch going through gentoo-pms at least 21:20:54 it looks good to me too, although I can't comment much on portage code (i.e. it went over my head) 21:21:14 Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml 21:21:19 Betelgeuse, good point, but you have seen the one posted to the list, right? 21:21:32 s/the list/the -dev list/ 21:22:22 my only comment is that it refers to the prefix stuff as coming with EAPI3 and that would have to be fixed if we vote to make a quick EAPI bump before 21:22:38 Calchan: yes there was one there 21:22:38 and I was satisfied with the answers 21:24:06 obviously there's some polishing required with all this, but we can vote now on whether we want prefix in the tree as it's been presented to us 21:24:14 I vote yes 21:24:33 I vote yes 21:24:38 yes too 21:25:02 yes 21:25:11 Betelgeuse? 21:25:27 leio? 21:25:53 Calchan: yes having prefix support eventually in the main three is worthwhile 21:25:57 I abstain from voting, as I have not been able to review yet what has been presented to us. But in what way would this "wanting prefix in the tree" be as? 21:26:19 We already voted on the previous meeting on the general desire to see prefix in the main gentoo-x86 portage tree 21:26:45 leio, the question today is do we accept the technical proposition that is made to us today? 21:26:52 leio, but you can abstain 21:26:56 this is ok 21:27:01 thanks for clarification, good for summary 21:27:07 Betelgeuse, do we have a yea from you? 21:28:24 right now we have 4 yes, 1 abstention, and one that I think is a yes but would like confirmation ( Betelgeuse) 21:28:28 Calchan: I will abstain from voting on the PMS patch itself as I haven't read/seen any follow up with pms committers 21:28:50 Betelgeuse, ok, how do we count you though? 21:29:00 for summary purposes only 21:29:08 because we already have a majority 21:29:31 Calchan: If you clarify the vote as being about the patch: abstain 21:29:36 We already voted on intentions 21:30:08 I'm unclear on what is that technical proposition that is made to us today - is it the PMS patch at http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml ? 21:30:14 Betelgeuse, ok, although we have the PMS patch and lots of answers we didn't have previously 21:30:34 leio, PMS patch, all the answers in the thread, the portage branch 21:30:57 That's quite far reaching and hard or vague to summarize, but OK... 21:31:17 ok, then we have 4 yes and 2 abstentions 21:31:34 prefix can proceed to the tree 21:31:47 3.2 EAPI bump for prefix 21:31:56 we have the following choices: 21:32:02 3.2.1. Should we make a quick, prefix-specific EAPI bump? 21:32:10 3.2.2. Should we wrap together prefix plus whatever features of EAPI3 which are already ready into an intermediate EAPI and ship that now? 21:32:14 3.2.3. Should we add prefix to EAPI3 and ship it all together when what's missing of EAPI3 is ready? 21:32:33 does anybody need clarifications on the above propositions? 21:32:39 we can discuss a bit and then vote 21:32:45 I don't think 3.2.2. makes sense. It's easier to have an EAPI that only prefix devs need to care about or then having altogether useful EAPI 3. 21:32:54 Betelgeuse, agredd 21:33:20 so 3.2.1 means we rename EAPI 3 to EAPI 4? and EAPI 3 would be the prefix one? 21:33:35 ulm: We don't have to name EAPI N 21:33:38 ulm, I think the naming is just a cosmetic issue 21:33:43 ulm: It can be 2+prefix for example 21:33:47 we can decide that later 21:33:49 to make it clear 21:34:07 Betelgeuse: true, but integers make a nice scheme ;) 21:34:32 nicer than 2+prefix or 2/prefix or whatever 21:34:53 ulm, we could go 2.1 for example 21:35:02 Increasing integer strings seem easier to remember by developers (2+prefix would work now, but confusion starts with EAPI-3 then existing - does it include prefix support or not, etc) 21:35:24 but naming is naming, which option is the first question I suppose 21:35:35 problem with that is there are places in the tree that use EAPI as an int. 21:35:47 guys let's vote on the "what kind of bump first" we'll decide on the naming later, OK? 21:35:51 solar: those are QA violations 21:35:53 solar: is that so? eclasses? 21:36:04 Calchan: o.k. 21:36:21 ulm: I think some eclass and everywhere that checks for EAPI's <= 2 21:36:30 I vote for 3.2.1, aka let's make a quick bump now 21:36:50 3.2.1 from me, too 21:36:53 3.2.1 Yes as EAPI=3 21:37:07 Calchan: Do you know the latest opinion from grobian on this one? 21:37:21 Betelgeuse, last time I heard he didn't care much 21:37:27 3.2.1 or 3.2.3 for me, both work for me 21:37:28 grobian? 21:37:35 well 21:37:50 as I said, there is an option 3.2.4 21:38:04 dertobi123, you sound like my wife... ;o) pick just one... anyone 21:38:32 while 3.2.1 would be very very very cool, there is a little problem wrt to implementation, since Prefix Portage is autotool based, and normal Portage is not 21:38:41 Calchan: it's not to choose anyone ... 21:39:14 grobian, I'm not sure what difference you make between what you propose and 3.2.1 but go ahead and explain us 21:39:17 3.2.1 or 3.2.2 from me (it's not a yes/no vote, I can't just pick one) 21:39:21 hence 3.2.4: make a quick bump on EAPI that is upwards compatible with Prefix, and then get the full implementation sorted out lateron 21:39:58 grobian, full implementation of what? prefix? 21:40:04 if so what could change? 21:40:19 Calchan: if you guys go for 3.2.1 I need to work with zmedico for some time to get prefix branch merged with trunk, delaying EAPI3 21:40:46 in principle the prefix branch is ready and waiting 21:40:56 grobian, then why the possible delay? 21:41:28 grobian: any numbers? is it a matter of hours? days? 21:41:28 Calchan: because Prefix branch is based on trunk, not on the 2.1 branches, and uses a different build system 21:42:07 ulm: I think it is a bad idea to blindly rely on my python coding skills for ~arch of Gentoo Linux 21:42:16 simply like that 21:42:26 so zmedico needs to review 21:42:59 therefore we would like to have the specification available in the next EAPI 21:43:21 so we can use Prefix next to normal Gentoo 21:43:28 grobian, not a show stopper to me, get your thing in a working state and with the proper build system quick enough that it doesn't delay EAPI3 21:43:44 Well not delay by months 21:43:52 a month no-one notices 21:44:05 Calchan: if that's what you want, I can try and put the maximum efforts in it to get that done 21:44:08 grobian, then we'll take bets on who's ready first, if I lose you get whipped ;o) 21:44:26 Calchan: it'll be a joint with zmedico 21:44:35 so I'll always win 21:44:44 because the code is already there 21:45:09 nobody cares what I think, let's vote though 21:45:29 Calchan: see above 21:45:30 I'd be delighted with 3.2.1 21:45:30 could you guys please say again which one(s) you'd vote for even if there's more than one? 21:45:36 3.2.1 21:45:49 3.2.1 Yes as EAPI=3 21:45:53 under the assumption that the prefix team is going to be fast enough with the implementation 21:45:56 solar, thanks 21:46:00 and ulm 21:46:01 still 3.2.1 or 3.2.3 for me, both work for me 21:46:13 I'm for 3.2.1 and 3.2.2 21:46:25 we'll have to do a quick majority vote here, but no big deal 21:46:36 3.2.4 21:46:49 3.2.1 or 3.2.2 21:46:59 3.2.4 conflicts with your earlier decision this evening, by the way 21:47:33 Calchan: looks like we'll have to do a condorcet vote now ;) 21:47:51 ulm, no majority will be enough since it's not a secret vote 21:48:05 I'm missing one vote... who? 21:48:10 ah leio 21:48:14 ? 21:48:25 21:46> 3.2.1 or 3.2.2 21:48:42 ok, the results are: 21:48:55 3.2.1: 5 21:49:00 3.2.2: 2 21:49:05 3.2.3: 3 21:49:13 sorry 21:49:18 3.2.3: 1 21:49:28 3.2.4: 1 21:49:37 looks like 3.2.1 wins 21:49:59 barring any computational error from my pen&paper computer system 21:50:03 --- fox2mike_ is now known as fox2mike 21:50:26 so now we can discuss how we call it 21:50:34 --- fox2mike is now known as Guest9920 21:50:43 we already know solar wants to call it EAPI3 21:50:49 others? 21:50:54 != 3 21:50:59 let's call it EAPI 3 21:51:28 EAPI 3 21:51:33 eapi3 works for me, if we rename what was eapi3 to eapi4 21:51:43 dertobi123: agreed 21:51:57 I'd vote for some 2 < number < 3 21:51:59 like 2.1 21:52:37 FYI, currently Portage itself treats EAPI as an integer (unless I'm mistaken) 21:52:59 so we have 4 votes for EAPI3 and 2 against 21:53:05 EAPI3 it is then 21:53:31 * Calchan slaps ABCD with a PMS printout for speaking without voice :o) 21:53:35 ABCD: It should be fixed then 21:53:56 * ABCD also notes that this channel isn't +m... 21:54:08 ABCD, yes, we suck 21:54:09 right, it should be fixed, but by calling it 3 we don't risk any breakage 21:54:32 any more comments on the prefix topic? 21:54:38 Do we write EAPI-3, EAPI 3 or EAPI3? :) 21:54:39 ABCD: you're mistaken ;) 21:54:59 leio: EAPI=3 :p 21:55:11 grobian, congrats btw, you just got yourself and your team a shitload of work 21:55:19 yeah, thanks a lot! 21:55:41 heh 21:55:51 if there's no more comments on prefix then we'll move on 21:56:06 4. GLEPs 58, 59, 60 and 61 is moved to open floor, so: 21:56:11 5. mtime preservation 21:56:13 ysy 21:56:14 yay 21:56:50 does anybody want to discuss anything on this topics before we vote? 21:56:52 What's the opinion of pkg maintainers who need mtime preservation? 21:57:00 Do we have any around? 21:57:05 --- Calchan gives voice to ferringb 21:57:07 Betelgeuse: me ;) 21:57:23 ciaranm isn't here 21:57:24 ulm: yay remembered right then but wasn't sure 21:57:44 whoever you are, if you want to talk for paludis just ping me 21:57:52 Betelgeuse: the feature is really needed for several lisp packages 21:58:03 although you don't need voice to speak as we're not +m 21:58:28 ulm: Yes but what's your preferred way out of 5.n doing in ebuild side? 21:58:43 Betelgeuse: both 5.1 and 5.3 work 21:59:17 ulm, do I understand 5.1 works if it's made equal to 5.3 or works unconditionally? 21:59:20 5.2 would require that we change at least two eclasses and several (about 50?) ebuilds 21:59:38 5.2 seems like it's written in order to make us reject it 21:59:39 Calchan: it works unconditionally 21:59:47 ulm, ok thanks 22:00:23 solar, I find the solution rather elegant even if less practical than the others 22:00:39 --- Guest9920 is now known as fox2mike 22:00:55 I find the lack of stripping objects in the name of saving mtime to be stupid 22:01:18 do we want to vote now? I rebooted my pen&paper computer system 22:01:39 I am off to toilet, I will go with whatever ulm chooses as they are the ones using it 22:01:47 solar: so mtimes for stripped objects should be preserved too, in your opinion? 22:02:23 ulm, I'd say yes if we wanted to make it the right wa, the real question is do we? 22:02:25 ulm: as noted. Being that there is no consensus among PM devs. 5.3 seems ideal for now. 22:02:33 strip from toolchain has a --preserve-dates option btw 22:02:56 ok, solar votes 5.3, ulm and Betelgeuse 5.1 or 5.3, others> 22:03:01 ? 22:03:13 Calchan: I'd prefer 5.1 but 5.3 works too 22:03:25 ulm: the way 5.2 is written. It favors mtime over stripping. IE skip stripping it sounds like 22:03:42 ulm, I can count you as 5.1 if you want, my system has an eraser :o) 22:03:57 and limits it to a given eapi vs being retroactive and a basic feature of the PM 22:04:53 ulm? so you want 5.1, or 5.1 and 5.3? 22:05:13 and I vote 5.3 btw 22:05:21 Calchan: 5.1 with fallback to 5.3 ;) 22:05:34 5.3 wfm 22:05:40 leio? 22:06:02 abstain 22:06:07 ok 22:06:38 we have 2 for 5.1 and 5 for 5.3 22:06:58 so we'll document protage's behavior and will put that into PMS 22:07:08 Calchan: count me as 5.1 please 22:07:16 ulm, can you take care of that with for example zmedico ? 22:07:30 *sigh* yes 22:07:47 ulm, ah ok, so we have 2 for 5.1 and 3 for 5.3 22:08:01 into PMS as EAPI-0 clarification or? 22:08:29 leio: EAPI 4, unless we vote otherwise now 22:08:59 EAPI3+1 for me 22:09:06 =EAPI4 22:09:16 3 or 4 22:09:33 ah right, sticking that with prefix is a good idea 22:09:49 good idea 22:09:56 Calchan: can you write out how you counted who as to avoid any misunderstandings? 22:10:05 leio, ok 22:10:20 Betelgeuse and ulm 5.1 22:10:32 dertobi123, solar and Calchan 5.3 22:10:39 leio abstention 22:10:49 is it ok for everybody? 22:10:53 yes 22:10:57 I can go either way on 5.x 22:11:09 Calchan: then we don't have a decision? 22:11:24 Calchan: There's someone missing 22:11:27 solar, then make your mind and tell us 22:11:34 Nobody said anything about making it a new EAPI however 22:12:12 portage is not going to limit it's behavior to do this only-if-eapi>=3 22:12:17 solar, let's decouple the EAPI issue then 22:12:24 please lets. 22:12:27 solar: It wouldn't make any practical difference for portage and pkgcore 22:12:34 since they already comply 22:12:55 solar, the point would be to document what can be relied upon starting with EAPI3 22:12:56 ulm: right. But till this meeting nobody said anything about making it an EAPI change. 22:12:59 not changing enyhting 22:14:59 so, have we accepted 5.3 or what? 22:15:00 so, anybody who wants to reconsider his vote? solar? then we can discuss the eapi issue 22:15:13 Note that on 12th October meeting we re-opened what was known as EAPI-3 for mtime preservation 22:15:46 (but nvm) 22:16:32 solar? do you reconsider your vote or you keep 5.3? 22:17:46 I'm still in favor of 5.3 22:17:49 ok 22:17:53 On 12 October meeting we also voted "A: current Portage and Pkgcore behaviour, all mtimes are preserved" with a clear majority, was this topic re-opened since then? 22:18:18 leio: no, just clarifications to it 22:18:23 ok. 22:18:26 leio, the issue was about documenting 22:18:35 leio: Basically sub seconds involved 22:18:46 I need to go. For any remaining open topics and I don't think any remain. See email. 22:19:31 >grobian< hey, do you have quick links for the prefix support discussion thread and a link to the prefix portage branch, for the purpose of the meeting summary? 22:19:31 solar, thanks, I think we're good 22:20:28 we're done? 22:20:33 now the question is do we apply the documenttion change to all EAPIs retroactively? to the newly defined EAPI3? or to EAPI4? 22:20:47 3 22:20:51 dertobi123, no but we'll use his email 22:20:56 I vote 3 too 22:21:36 3 22:21:40 I vote EAPI3 or retroactively 22:21:48 dertobi123? 22:22:21 for all eapis retroactively makes sense for me, as that's what portage is doing for quite some time - but making it part of our new eapi-3 works as well 22:22:34 really it doesn't make any practical difference 22:22:37 thanks 22:22:53 so we have 5 votes for EAPI3 and 2 for retroactive 22:23:17 so basically "Since EAPI-3 this behaviour can be relied on in all PMS compliant package managers" 22:23:20 we'll define mtime preservation based on what portage does today in EAPI3 onwards 22:23:36 right 22:23:50 ack 22:23:52 and ulm you'll take care of the with whoever? is it ok? 22:24:08 Calchan: I'll talk to Zac 22:24:13 and anymore comments on this topic before we switch? 22:24:49 ACTION: ulm to talk with Zac about defining current portage behaviour for documenting in EAPI-3 22:24:59 thanks leio 22:25:07 and I understand we can move on 22:25:23 6.1 logs? summary? I can do summary if nobody wants 22:25:31 I have the summary almost ready 22:25:39 Logs I will commit today 22:25:40 leio, great thanks 22:25:41 leio++ 22:25:42 leio++ for that 22:25:43 --> Ramonster (n=ramonvan@ramonvanalteren.xs4all.nl) has joined #gentoo-council 22:25:54 6.2 next meeting? 22:26:03 I'd like to delay by one week 22:26:08 Sorry for slacking on the previous ones (see my private e-mail), writing it during the meeting works a lot better 22:26:23 I am fine with either delaying or not 22:26:28 we've been meeting every 4 weeks instead of every month so we gained a couple weeks on the way 22:26:40 and I'm not sure my brain and liver will be up to speed 22:27:07 4 or 18 are best for me in January 22:27:14 well != 11 22:27:21 Exams on 12 22:27:26 so, january 18th then? 22:27:44 solar probably has a work meeting 22:27:44 18th seems a bit late, in which case I don't mind doing it on the 4th 22:28:08 so we might want to ask what suits him 22:28:28 Betelgeuse, I'll see with him if another day of the week would help 22:28:47 Betelgeuse, your exams are on the 12th only or all week? 22:28:48 May I request that the council consider adding *.xz/*.tar.xz to unpack() for the new EAPI-3 (instead of waiting until EAPI-4)? (or should that wait until the next meeting? Portage already has support, but disabled for older EAPIs) 22:28:54 Calchan: all week 22:29:09 ABCD, not the time and place to do that, send an email to the list as usual 22:29:18 Calchan: okay 22:29:29 Betelgeuse, so let's see with solar what day in the week of the 4th he prefers 22:29:51 does anybody have a preference for a day in that week? 22:30:13 before friday 22:30:22 not me, but maybe we need to re-consider Monday if his meetings are always on Mondays? 22:30:32 (I mean not for just one meeting, but overall) 22:30:41 --> ulm__ (n=ulm@p4FD3F0D7.dip.t-dialin.net) has joined #gentoo-council 22:30:43 leio, yes 22:30:51 what about starting a new doodle-poll for the january meeting? 22:31:11 <-- ulm has quit (Nick collision from services.) 22:31:17 --- ulm__ is now known as ulm 22:31:20 so if everybody agrees we'll have next meeting on that week of january which starts on the 4th, we need to decide what day exactly 22:31:31 sorry, network hiccup 22:31:33 dertobi123, great, can you take care of that? 22:31:46 who does the agenda next time? 22:31:57 Calchan: i'll try to do so, yeah 22:32:17 ACTION: dertobi123 to check what day of the week is best for council members nowadays, possibly rescheduling the next meetings date 22:32:27 and follow up topics, just doing the agenda is not enough, devs need to be pushed to do the right thing 22:32:47 --- ChanServ gives channel operator status to ulm 22:33:21 I can't do the agenda as I will be without internet for 2 weeks around christmas and new year 22:34:25 --- dabbott|away is now known as dabbott 22:34:32 if nobody volunteers I can do it if we delay the meeting by at least one week 22:34:33 I will mostly be reading for exams so I would prefer someone else 22:34:50 Betelgeuse, yes, don't sabotage your exams 22:35:16 Calchan: Well Finnish system gives you infinite retries 22:35:25 I don't mind doing it if we agree to delay 22:35:32 Betelgeuse, but life doesn't ;o) 22:35:35 So sabotaging is impossible :) 22:35:45 works for me, besides that i'd like to see luca or solar doing an agenda, too 22:36:40 btw. luca ... 22:36:56 dertobi123, luca has been pretty much inactive so he may not have enough time (and I'd prefer this be done correctly as it's important) and solar is reconsidering all his gentoo activities due to work 22:38:04 dertobi123, please add to your the possibility to delay the meeting to the week of the 18th, in which case I can take care of the agenda 22:38:14 s/to your/to your poll/ 22:38:39 so well, yeah ... speaking of luca ... he missed the july and august meetings according to the logs and he missed this meeting, too. if we follow glep 39 it's time to elect a replacement for luca :/ 22:38:41 that's like two polls then, day in general, and week 22:39:09 dertobi123, we usually don't elect and pick the next in list 22:39:18 which would be bonsaikitten 22:39:30