21:00:06 --- dertobi123 sets mode +m #gentoo-council 21:00:09 hi 21:00:11 Betelgeuse, dertobi123, solar? 21:00:14 Calchan: yes 21:00:26 * scarabeus aroundy :] 21:00:31 ok, so it looks like we're only missing solar 21:00:45 why do you say that? 21:00:59 solar, oh sorry, hi :o) 21:01:06 :] 21:01:54 ko, so who's logging? 21:02:00 I am 21:02:03 good 21:02:13 anyone else, just in case? 21:02:14 * wired logging as well 21:02:17 great 21:02:21 roll call 21:02:25 here 21:02:31 here, proxy for leio 21:02:32 here 21:02:44 still here 21:02:46 I'm obviously here :o) 21:02:47 likewise 21:03:01 dertobi123, is here too, still alive ? ;o) 21:03:13 yep 21:03:15 somewhat 21:03:17 great 21:03:23 who wants to chair? 21:03:39 I can as I know the topics, but anybody else is welcome to volunteer 21:03:45 Please do 21:03:45 feel free 21:03:46 Calchan: no objections 21:03:53 ok then 21:04:02 any remarks on the agenda? 21:04:22 Calchan: Could get comments on the council web app at end if there's time but unlikely 21:04:30 Calchan: As I didn't get much on the mailing list 21:04:33 and scarabeus is new 21:04:35 after 4 we need to officially approve eapi3 if the status report of 2 and 3 is OK 21:04:54 yes 21:05:02 Betelgeuse, yes, let's discuss that i n the open floor part if you want 21:05:16 --> ssuominen (n=ssuomine@gentoo/developer/ssuominen) has joined #gentoo-council 21:05:22 I couldn't comment on that, I was too busy with other ongoing subjects 21:05:35 any other comments? 21:05:48 --- Calchan gives voice to grobian 21:06:11 ok, let's moce to 2. prefix status 21:06:23 --> Cardoe (n=Cardoe@gentoo/developer/Cardoe) has joined #gentoo-council 21:06:34 grobian, can you tell us how prefix is progressing? 21:06:39 my typing sucks today 21:06:43 Calchan: fairly well, I'd say 21:06:51 as far as I know, portage is ready 21:07:00 ok, what was done, and what still needs to be done? 21:07:03 it seems the PMS patch needed a final review by the council 21:07:09 ok 21:07:18 so thanks to ulm the patch has been brought into a final state 21:07:40 I personally see nothing that needs to be done 21:07:49 grobian, am I right in thing that there's nothing pending before finmal approval? 21:07:51 lots of peeps actually started porting stuff 21:07:56 /thing/thinking/ 21:08:21 Calchan: as far as I am aware, all objections/questions by PMS team were dealt with 21:08:30 I'd have to ask ulm to make that official 21:08:42 yes, I think so 21:09:05 so if other council members agree we will consider prefix done and not a blocker for final approval of eapi3 then 21:09:09 there were no more comments on the last version of the patch 21:09:25 can I get a quick yes from everybody on the above question? just a formality... 21:09:27 <-- Arfrever has quit (Client Quit) 21:09:41 so that's a yes from me 21:09:43 here's your "yes" 21:09:45 +1 here 21:09:46 yes 21:09:51 here is 1 "yes" 21:09:52 the approval is done by having something to tag in PMS before 21:10:03 if it's not committed yet then there's no commit to review and tag yet 21:10:13 sigh 21:10:18 but conceptually yes 21:10:22 Betelgeuse, we have a patch so it's as good 21:10:23 it's committed: 21:10:32 ulm, thanks 21:10:32 ulm: good 21:10:44 solar? although we seem to have a majority here 21:11:40 Calchan: one moment 21:11:44 solar, sure 21:13:22 solar, let's move one as we have a majority anyway, and feel free to chime in with your opinion on that at any time during the meeting when you're more available 21:13:38 so let's move to : 3. mtime preservation status 21:13:41 ulm? 21:14:08 I seem to remember there was a minor point still to be dealt with, what was it again? 21:14:18 no, all issues resolved 21:14:26 nothing that I would consider big enough to block eapi3 approval though 21:14:30 consensus with PMS team and all PM authors 21:14:40 ulm, but can you still please remind us what it was? 21:14:47 just out of curiosity 21:15:10 Calchan: I voted last month to approve the prefix stuff. My vote from then still stands. So yes. 21:15:12 there was an issue with nanosecond time stamps 21:15:18 solar thanks 21:15:27 ulm ah yes 21:15:30 but it has been resolved 21:15:49 here's the commit in PMS: 21:16:02 ok, so do we all agree on final approval of mtime preservation for eapi3? 21:16:06 yes from here 21:16:09 yes 21:16:13 yep 21:16:52 yep 21:16:56 yes 21:17:03 reading 21:18:26 looks good, yes 21:18:49 alright we have a majority anyway, solar you can take your time 21:18:53 what is this subsecond stuff being slipped in? 21:19:27 solar: basically, it says that subseconds must be set to zero or preserved exactly 21:19:39 ulm: that is new. 21:19:51 so does this turn it's value into a float/double ? 21:20:15 solar: no, only intergers involved 21:20:19 --> yporti (n=yporti@r306-pb-passacinco.ibys.com.br) has joined #gentoo-council 21:20:19 *integers 21:21:07 solar, ulm, can we move forward or you need more time to discuss this now? 21:21:32 Calchan: move forward please, we can discuss it later 21:21:38 ulm, ok thanks 21:21:46 4. Should we move xz unpacking from EAPI4 to EAPI3? 21:21:51 solar: it's all fine, trust me ;) 21:21:57 this was actually my fault that this was not discussed last time 21:22:19 we had a PMS patch ready already, prtage has that implemented for quite some time 21:22:23 and it's trivial 21:22:32 --> Fauli (n=Opfer@gentoo/developer/fauli) has joined #gentoo-council 21:22:42 then lets get that in to eapi 3 21:22:47 My point previosly and still is keeping EAPI 3 as something that most developers wouldn't need to know the contents of 21:22:59 its two liner iirc :] 21:23:00 dertobi123, we still need to vote on xz though 21:23:13 If we have repoman verifying proper .xz usage then it's fine for me 21:23:23 and its a yes from me 21:23:35 well it is nothing required to know if portage handles it iself :] 21:23:37 Calchan: that was my vote ;) 21:23:41 fine as well on .xz 21:23:45 can anybody answer Betelgeuse on repoman? ping me in private if you need voice 21:24:02 and a yes from me 21:24:24 we already have a majority anyway 21:24:25 iirc it does not bail out now, since we have xz packages in kde4.4 snapshots 21:24:37 and we supply the .xz tarballs and own extract function 21:24:51 only problem with it is depending on proper tar version that supports xz 21:25:01 scarabeus: Should we start forcing EAPI 3 or later for .xz? 21:25:05 Such a repoman patch is easy 21:25:26 .xz in eapi 3 fine for me as well 21:25:40 What does Portage do for .xz files in EAPIs 0 1 2? 21:25:44 we should push it throught, because few upstreams use only xz as sources, and the custom unpacks are lame 21:25:53 Betelgeuse: unpack ignores them 21:26:06 I remember some extension being pushed without EAPI bump but it was probably lzma related 21:26:28 as far as I can see we have everything approved for eapi3 so unless you speak now we have final approval for it 21:26:50 ulm: Ok which is probably not what the user wants so EAPI 3 repoman check should be ok 21:27:04 Calchan: so we include xz or not? 21:27:15 we do 21:27:17 ulm, looks like it, yes :o) 21:27:20 k 21:27:23 Calchan: assume yes from me on the eapi3 mtime. 21:27:30 I will file a bug for repoman and xc 21:27:31 solar, ok thanks 21:27:36 Betelgeuse, good point 21:27:48 should we move forward? 21:28:13 5. GLEP 57 21:28:23 https://bugs.gentoo.org/show_bug.cgi?id=301426 21:28:45 it's in informational glep on tree signing and security in general 21:29:06 if you want to discus it (briefly) speak now, or we'll move to vote on it 21:29:46 Calchan: we don't approve eapi 3? 21:29:59 I was mainly thinking do we need informational docs as GLEPs 21:30:01 --> romi (n=Rodrigo@mail.ltia.fc.unesp.br) has joined #gentoo-council 21:30:09 ulm, you want a specific vote for it? that's ok with me 21:30:23 let's vote for final approval of eapi3 then 21:30:27 yes 21:30:30 Calchan: i think it would be appropriate 21:30:35 yes for eapi3 21:30:35 yes 21:30:35 here's your yes :) 21:31:04 grobian, can you please take care of the champagne in the meantime? 21:31:12 yes 21:31:13 Calchan: you're just too late 21:31:17 Betelgeuse: wrt informational docs - i don't think we *need* those as GLEPs, but it doesn't hurt to have one as a GLEP 21:32:00 we have a majority for eapi3 final approval, so as of right now eapi3 is offically official 21:32:24 ulm: as you have commit rights it's easiest for you to tag it 21:33:02 let's move to GLEP 57 now 21:33:05 Betelgeuse: I don't, but I'll ask fauli 21:33:15 yes for eapi3 for formality :) 21:33:17 We are going to have a hard time talking about these gleps 57-61 if robbat2 does not show up. 21:33:26 ulm: The tags have been signed by council members 21:33:37 the first one is ok 21:33:40 Betelgeuse: ok, will do then 21:33:49 it just sums up the reasons and whats going on :] 21:33:55 solar, he said he probably wouldn't though and I think most of us have discussed it with him before 21:34:21 ulm: I remember using a bundle or something like that and emailing that to someone who can commit 21:34:58 technically all we need to do is vote yes or no, and no might mean not yet, discussions should have happened before as this has been in the making for years 21:35:12 --- Calchan gives voice to Fauli 21:35:53 Fauli, you have voice now so go ahead 21:35:59 Betelgeuse: I can commit, as Ciaran is not available for some days. 21:36:15 As soon as you are ready, send it my way. 21:36:26 <-- Cardoe has quit (Remote closed the connection) 21:37:18 ok, so since there does not seem to be any discussion about glep 57, let's vote 21:37:37 I vote yes, as in it's informational only but states some necessary goals 21:37:54 yes for 57 21:38:06 glep 57 - yep 21:38:15 yes 21:38:21 yes 21:38:26 yes 21:38:41 good, we have a majority for yes, glep 57 is approved 21:38:52 6. GLEP 58 21:39:39 58 is about implementing metamanifest which does not require developper action 21:39:56 same thing, vote or comment please 21:40:04 I assume robbat2 has done testing in practise from the latter GLEPs so no objections here 21:40:14 --> _robbat2laptop (n=robbat2@gentoo/developer/robbat2) has joined #gentoo-council 21:40:15 first we'd need to vote for glep-60, as this one is required by 57 21:40:22 --- Calchan gives voice to _robbat2laptop 21:40:26 yay 21:40:33 <_robbat2laptop> sorry, in work meeting, and had bad wifi till now 21:40:41 the size of the metamanifest is very large if there are no subdir (i.e. categories + eclass + profiles) metamanifests 21:40:56 _robbat2laptop, we approved 57 and were just starting 58 21:41:11 <_robbat2laptop> ulm, the metamanifest spec does specify subdirs Manifests are strongly suggested 21:41:15 ulm, agreed but there's glep 61 to the rescue 21:41:39 _robbat2laptop: maybe council should support this suggestion then 21:42:13 ulm, we can make a specific note of it but it being in the glep already is enough for me 21:42:41 I would vote yes on this one, my only concern is about infra havong the manpower to actually implement that 21:42:56 <_robbat2laptop> Calchan, there's a functional MetaManifest generation prototype already 21:43:03 <_robbat2laptop> in my other dir on the gentoo CVS repo 21:43:10 and how is the final file? 21:43:13 how big 21:43:33 _robbat2laptop: Have you tested how much slowers emerge --sync becomes? 21:43:44 solar: I think it was 8 MB if without subdir manifests 21:43:59 ulm, compressed or not? 21:44:21 <_robbat2laptop> 8MB uncompressed without subdirs 21:44:37 not that big of a deal then 21:44:46 <_robbat2laptop> if subdirs are used, it's about 8.05MB raw 21:45:16 the compression factor cannot be good for SHA hashes 21:45:39 mainly factor of 2 for ascii -> binary 21:45:48 _robbat2laptop, can you confirm that e.g. users on low bandwidth can deactivate this? 21:45:49 <_robbat2laptop> better than 2:1 21:46:00 <_robbat2laptop> Calchan, they can add --exclude MetaManifest* 21:46:12 <_robbat2laptop> they wouldn't be able to validate the tree as easily 21:46:19 <_robbat2laptop> but that is a tradeoff they have to decide 21:46:43 then if it can be deactivated and we have an already (at least partially) working implementation I vote yes 21:46:47 what about others? 21:47:00 _robbat2laptop: I don't think you answered the speed implications 21:47:34 <_robbat2laptop> Betelgeuse, without the split, it's a new MetaManifest file nearly every rsync pass 21:47:57 _robbat2laptop: I mean how long does verifying the Manifests add to the time 21:47:58 <_robbat2laptop> with the subdir split, the extra data transfered is <2MB in my tests 21:48:03 we should maybe enforce the splits instead of recommending 21:48:22 scarabeus, good point 21:48:23 _robbat2laptop: Mainly if there's anything major for older machines? 21:48:23 2mb isn't that bad 21:48:40 scarabeus: that sounds good 21:48:47 _robbat2laptop, what's the cost/implications of splitting? 21:48:48 <_robbat2laptop> Betelgeuse, I had full signature verification of _every_ Manifest and MetaManifest in <5 seconds, plus any IO time 21:49:07 _robbat2laptop: ok thanks 21:49:14 <_robbat2laptop> cputime ~5 seconds on a not fast P4 box, ~3 years ago 21:49:14 Calchan: in short it's faster if split. 21:49:35 <_robbat2laptop> yes, because the subdir MetaManifests might not have changed between passes 21:49:35 solar, that's what I thought but I was afraid there was a downside to it 21:49:44 <_robbat2laptop> ~50 more inodes 21:49:48 8M ? there is too much overhead in this format 21:49:57 <_robbat2laptop> 8M uncompressed 21:49:59 if there is no downside I'd be in favor of making it mandatory 21:50:05 <_robbat2laptop> that's why there was the compression GLEP 21:50:10 I just hashed the entire tree sha1 @ around 3.6M 21:50:47 but sha256/512 is longer 21:51:26 are we ready to vote on this or do you need more time to discuss? 21:51:33 <_robbat2laptop> http://dev.gentoo.org/~robbat2/MetaManifest.bz2 21:51:38 _robbat2laptop: You are not filering the files that are moot? 21:51:45 <_robbat2laptop> from July 2008 21:51:51 like ChangeLog/metadata.xml and other manifests? 21:52:04 <_robbat2laptop> solar, every file should turn up in exactly on Manifest file 21:52:11 <_robbat2laptop> *exactly one 21:52:16 <_robbat2laptop> MetaManifest or Manifest 21:52:25 <_robbat2laptop> but no single file should be in more than one Manifest 21:53:58 is there any valid reason to checksum metadata.xml or ChangeLog files in this format? 21:54:26 <_robbat2laptop> solar, the added filetypes GLEP deals with when they can be excluded 21:55:08 _robbat2laptop: about 2/3 of the metamaifest size are due to metadata/cache? 21:55:19 <_robbat2laptop> ulm, yes unfortuntely 21:55:22 what number is that? these gleps kinda make you just back and forth. Making it a bit difficult to follow 21:55:26 <_robbat2laptop> and those files DO need to be protected 21:55:42 scarabeus: 60 21:55:46 oops 21:55:50 solar: ^^ :) 21:56:48 <_robbat2laptop> 58 - MetaManifest itself, 59 - hash types (SHA512), 60 - filetypes, 61 - compression 21:57:12 are we ready to vote on glep 58? 21:57:52 no 21:58:04 I can say. I'm ok with the idea as a whole and would like to see a compressed per cat metamanifests 21:58:19 solar, you need more time to discuss or you're voting no? 21:58:20 but these gleps don't allow you to vote on one of them. 21:58:49 and 60 looks like a format change in portage 21:58:58 <_robbat2laptop> ok, let's just tackle them in a different order for a sec. 21:59:06 <_robbat2laptop> 61 is allowing compression in ANY manifest 21:59:09 <_robbat2laptop> not just the MetaManifest 22:00:43 solar, if you think they're not ready to be approved then vote no, ok? 22:00:55 wait a sec plz. 22:01:08 you guys even know what you are voting on? 22:01:26 as much as always :) 22:01:39 solar, I have provisions to add to my vote but I'm ready to vote 22:02:11 guess i do, and given the impact i'm against rushing this through today, especially if anyone of us has points he'd like to see adressed before voting 22:02:21 tjose provisions are btw that it is optional for the user and not on by default a tthe beginning, and that subdir splitting is mandatory 22:04:02 <_robbat2laptop> Calchan, is having the users that don't want it add --exclude MetaManifest* to their sync options acceptable? 22:04:52 _robbat2laptop, I wuold prefer the contrary at the beginning, i.e. users having to turn the feature on to use it 22:04:55 <_robbat2laptop> Betelgeuse, dertobi123, leio, scarabeus, solar, ulm: could you list what changes you would like? 22:05:04 can we go throught rest of those (1glep in 4) and add all comments under which it can be accepted, and we can proceed with vote next time on all of them at once if anyone is not against? 22:05:15 <_robbat2laptop> Calchan, ok, if we roll out an upgrade of portage that includes that? 22:05:30 perhaps we could tackle these gleps one/two at a time? 22:05:34 _robbat2laptop, yes ok from me at this condition 22:05:35 <_robbat2laptop> ok, so no metamanifest yet, move on to the next glep 22:05:53 scarabeus, wired hold on, let's stick to the agenda for the time being 22:05:54 <_robbat2laptop> i'll represent GLEP58 with more changes 22:06:14 glep 59 is rather orthogonal to the others 22:06:31 _robbat2laptop: GLEP 59 seems a bit outdated for python versions but that's just cosmetical 22:06:39 _robbat2laptop: Could make it reflect the current situation 22:06:41 has everybody read it and does any og you have questions for _robbat2laptop? 22:06:42 <_robbat2laptop> 58, 59, 60, 61 are all orthangonal 22:06:45 _robbat2laptop: Re; Like. I'd like to simply see the MetaManifests in the per category basis compressed. Not including bloat files that portage already ignores by allowing you to --exclude=metadata.xml and --exclude=ChangeLog ; With no changes to the existing Manifest format 22:07:03 <-- billie has quit (Remote closed the connection) 22:07:08 --> billie (n=billie@gentoo/developer/billie) has joined #gentoo-council 22:08:07 _robbat2laptop, I had the following question about 59: 22:08:29 Second paragraph of "Checksum depreciation". Is the description still up-to-date about python support of various checksums? How about using external executables when python does not have support for a desirable checksum? 22:08:45 so the first parts can be introduced w/o major bloat or behavior changes in the PM. We review the overhead it causes on the rsync servers and decide from there if it safe to move fwd. 22:09:48 <_robbat2laptop> Calchan, yes, py2.5 and newer all support SHA512 22:10:18 we're seriously late now, here's what I propose: 22:10:24 solar: i like that suggestion 22:10:58 it doesn't look liketoday we're going to approve any of these gleps except for the informational one we have already approve 22:11:16 solar's suggestion is nice, or we can go the other way around and implement 59/60/61 first, then finish up with 58 when they're done 22:11:38 so I suggest that one of us (me if nobody volunteers but I would prefer somebody else) gathers a list of questions/remarks/provisions for robin tio update his gleps fpor next time 22:11:56 how's that? 22:12:00 <_robbat2laptop> i'll post each glep in the body of a mail to -dev 22:12:12 <_robbat2laptop> if you have an item, post a reply there as a new thread 22:12:35 does everybody agree postponing the rest of these gleps? 22:12:47 <_robbat2laptop> they've been presented for 2 months already, so I don't know why none of you except ulm have come to me with questions/changes 22:12:59 actualy we technicaly can accept the 61, and if we will not accept the Metamanifest itself, that section of sentence can be removed 22:12:59 because that glep apply to the Manifest2 too 22:13:16 _robbat2laptop: i read them on saturday first time ;] 22:13:27 scarabeus, let's keep that for when we have a clearer view 22:13:33 * solar has been reading them for ~4 years 22:13:59 if nobody disagrees right now with postponing I'll move to the next point] 22:14:39 _robbat2laptop: Because we need that web app of mine 22:15:06 can we make mandatory that next time we will only vote on them and all concerns will have to be settled up to that meeting (so we dont end up like today?) 22:15:21 <_robbat2laptop> any if you don't present your question in the next month 22:15:24 scarabeus: +1 22:15:26 <_robbat2laptop> you hold your tongue 22:15:29 scarabeus, eh, let me guess, you're new, right? ;o) 22:15:41 Calchan knew before the meeting that we would not vote on all. But would be doing this in phases 22:15:42 :D 22:16:08 solar, I'll pretend I disagree 22:16:20 okey okey :D 22:16:26 solar, what I actually told you is that you could vote no if you thought this wasn't ready 22:16:48 metamanifest aside, what are the objections to the other gleps? 22:17:02 I wasn't forcing anybofy to vote or even less agree to this, I was just putting this on the agenda as requested by robin 22:17:12 on the other hand you guys could have done your homework 22:17:18 anyway 22:17:33 10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now? 22:17:46 <_robbat2laptop> i'm going to part here now 22:17:47 there i have question 22:17:47 <_robbat2laptop> thanks 22:17:51 how is the git migration 22:17:59 <_robbat2laptop> scarabeus, RESO LATER 22:17:59 s/how/where/ 22:18:14 i mean migration for portage as the manager :] 22:18:22 <-- _robbat2laptop (n=robbat2@gentoo/developer/robbat2) has left #gentoo-council ("back to my other meeting") 22:18:28 because if portage is on git, tommy just can have another branch 22:18:37 scarabeus, when you have such questions you should ask in advance for them to be put on the agenda 22:18:59 scarabeus, and you don't need to be a council member for that, you don't even need to wait for a council meeting 22:19:21 let's go back to: 22:19:25 10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now? 22:19:25 imho that's nothing we'd need to vote on, it's zac's decision whether he wants to maintain the code in portage svn/git or not 22:19:53 but zac and thomas have asked for us to decide on that 22:20:08 I think they just want the format decision 22:20:34 well if zac is ok with it, i think portage-2.2 can be experimental for bit longer :] 22:20:53 where "bit" can vary :] 22:20:54 note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to help thomas maintain it, which ws thomas' main concern 22:21:14 go with git and do whatever branch magic wanted 22:21:17 which is what i said above with the question if they migrated to git yet? 22:21:20 Betelgeuse++ 22:21:28 besides that, i'd still say it's up to zac 22:21:42 scarabeus, there's a bug for that in the agenda if you want to read it 22:22:11 see;read 22:22:38 alright, so far we have: 22:22:56 no , go with git instead from Betelgeuse 22:23:10 and I have the same opinion/vote 22:23:26 dertobi123 says it's up to zac and zac says no 22:23:27 same. no portage-maintree. yes on new branch. 22:23:45 branch is 100% fine with me too 22:23:46 that's 4 nos with solar's 22:23:48 leave it up to zac 22:24:04 we attempted to. He did not want to think for himself this time 22:24:06 alright, we have a decision then, that's no to 10 22:24:06 no from me to, leave it to zac 22:24:09 *too 22:24:16 --- Calchan gives voice to Tommy[D] 22:24:20 hi Tommy[D] 22:25:03 afaik the migration of the portage repo to git should happen any day now 22:25:16 a git branch would be nice though 22:25:26 most say "no, go with git", but as robbat2 just said, that wont happen for now, so that means "no, no integration in the experimental portage-2.2* branch" 22:25:56 and also "no intregration within the next future" 22:25:56 Tommy[D]: that was about main tree 22:25:56 Tommy[D], the no above was for the migration of the tree to git, not the portage repo 22:26:15 right. That is also a no on portage-2.2 22:26:39 Tommy[D], the portage repo *is* being switched to git right now, it got delayed a bit for technical reasons but it's any day now 22:26:42 <-- romi has quit (Client Quit) 22:27:31 You can branch in svn as well. 22:27:38 but it sucks 22:27:44 is it possible to somehow put the whole mutilib code behind a USE flag in 2.2 to get more people to test it? 22:27:45 but it's not enough to hold anybody back 22:27:47 Tommy[D], again zac has agreed to help you maintain this, the fact that it's going to be an official branch maintained with zac will make it more visibla and it will get more testing 22:28:21 Can those, who vote against integration give me their technical reasons against it, preferable via mail on the #-dev ML thread? 22:28:22 wired: it can be FEATUREised, but the branch is easier 22:28:26 Calchan: Well I doubt there's really much people on anything else put main tree releases 22:28:39 wired: specialy with the GIT eclass 22:29:15 scarabeus: yeah but I was hoping for releases not live ebuilds :) 22:29:31 Tommy[D]: What do you mean with integration? 22:30:19 Betelgeuse: my request was merging into portage-2.2* branch, it was voted against, so i would like to know the reasons for the votes 22:30:25 Betelgeuse, Tommy[D], wired, scarabeus: I propose you go on with that discussion during the open floor session in a couple minutes 22:30:49 Tommy[D]: baby steps buddy. 22:31:01 let's finish with 11 and you can all resume this discussion 22:31:07 11. Conclusion 22:31:12 11.1 Action list. Who does what and when? 22:31:38 as actions I have gahter a list of questions/changes for robin 22:31:52 or lists if we want to do this per glep 22:31:58 who wants to do it? 22:32:00 I am in Finland only the first Monday of February 22:32:13 Otherwise I am in Bryssels or Vancouver 22:32:16 Betelgeuse, we'll come to that hold on 22:32:31 Calchan: Don't ask both :) 22:32:47 Calchan: Any way it excludes me from good agenda work 22:33:00 as I said I can volunteer for the questions to robin but I would really prefer somebody more technical takes care of it 22:33:12 solar? 22:33:33 anybody? 22:33:36 solar seemed to have the most to need for changing things so would make sense 22:33:50 Calchan: I can take it if nobody else volunteers 22:33:51 I can send him my last sentance. I expect he has his reasons for wanting to include metadata.xml/ChangeLog (I just don't understand them) 22:34:10 I don't know what concerns the rest of you had in the same/similar respects 22:34:13 ulm, thanks, I'll help you with that if you need 22:34:37 ok 11.2 Who takes care of the summary and log for this meeting? When? 22:34:49 when have leio and tanderson as volunteer for that 22:34:59 so I think we're covered 22:34:59 Calchan: leio volunteered so I have no objections 22:35:04 we still don't have a summary for october 2009 btw 22:35:22 ulm, leio said he was working on that in his latest email 22:35:31 11.3 Next meeting date/time. 22:35:41 I have a problem with the 15th of februiary 22:35:47 8th? 22:35:51 but any other days is ok 22:35:55 I like the 8th 22:36:13 its right after fossdem right? 22:36:16 looks fine 22:36:16 8th is ok, every other monday in february might not work for me 22:36:17 yep 22:36:45 Betelgeuse? 22:36:47 8th ok for me too 22:37:05 good. that is better for robins gleps to not make him wait another month 22:37:26 Calchan: I would need to remember when I am flying back 22:37:37 Calchan: I am guessing I am back before 19UTC 22:37:45 Calchan: I will mail if that's not the case 22:37:54 Betelgeuse, ok, we can confirm the date on the alias after the meeting 22:38:07 11.4 Who will follow-up discussions and prepare the agenda for the next meeting? 22:38:09 Calchan: I will mail and ask 22:38:16 Calchan: s/mail/phone/ 22:38:23 as always I volunteer but that shouldn;'tprevent any of you to step up 22:39:13 ok, I'll do it then 22:39:23 12. Open floor (ad libitum) 22:39:39 19:25 22:39:43 you can discuss multilib again now, and any other topic 22:39:47 19UTC doesn't work 22:40:02 I am home 20UTC 22:40:04 Betelgeuse, are you availableon the tuesday? 22:40:10 yes 22:40:35 then I propose tuesday, let's settle that on the alias 22:40:53 somebody takes care of the +m while I go have some lunch? 22:41:03 --- Betelgeuse sets mode -m #gentoo-council 22:41:10 Calchan: /mode -m ? 22:41:17 Tommy[D]: I still have a bunch of questions about the multilib/stuff. I'll be back in 10-15 if you want to chat some more 22:41:44 wrt git branch: that wont help with additional testers/users, since they would do the same as now, in addition they would have to use a live version or something like my current multilib branch, so that would be of no big advance 22:42:07