diff options
Diffstat (limited to 'meeting-logs/20131119.txt')
| -rw-r--r-- | meeting-logs/20131119.txt | 382 |
1 files changed, 382 insertions, 0 deletions
diff --git a/meeting-logs/20131119.txt b/meeting-logs/20131119.txt new file mode 100644 index 0000000..48f014b --- /dev/null +++ b/meeting-logs/20131119.txt @@ -0,0 +1,382 @@ +[20:02:51] * dilfridge has changed topic for #gentoo-council to: "Next meeting: 19 Nov 2013 at 19:00 UTC, i.e. NOW | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://article.gmane.org/gmane.linux.gentoo.devel.announce/2029" +[20:03:12] <dilfridge> ok lets get this meeting started! +[20:03:18] <blueness> roll call! +[20:03:33] <dilfridge> blueness: dilfridge: rich0: scarabeus: ulm: WilliamH: dberkholz - roll call! +[20:03:38] -*- rich0 here +[20:03:45] --> dberkholz|web (0cb05905@gentoo/developer/dberkholz) hat #gentoo-council betreten +[20:03:46] -*- blueness here +[20:03:49] <dberkholz|web> hi +[20:03:55] -*- ulm here +[20:04:05] <dberkholz|web> can't ssh to woodpecker for some reason so enjoying freenode's web interface +[20:05:18] -*- dilfridge is picking out WilliamH and scarabeus mobile numbers +[20:05:33] <dberkholz> ah, there we go. +[20:05:36] <dberkholz> yay for hotel internet +[20:07:20] <dilfridge> ok I messaged WilliamH, +[20:07:32] <dilfridge> will do scarabeus and then we start +[20:08:11] <blueness> k +[20:08:41] -*- WilliamH is here +[20:08:49] --> graaff (~graaff@gentoo/developer/graaff) hat #gentoo-council betreten +[20:09:05] <dilfridge> done +[20:09:14] <dilfridge> if he doesnt turn up now there's no help :) +[20:09:20] <dilfridge> ook +[20:09:22] <scarabeus> ah thanks for the ping +[20:09:25] -*- scarabeus here +[20:09:28] <dilfridge> :) +[20:09:40] <dilfridge> Now, let's REALLY start. +[20:10:05] <dilfridge> Agenda topic 2: Request for a minimal policy for pgp keys and key handling (for commit +[20:10:05] <dilfridge> signing) +[20:10:21] <dilfridge> did robbat2 send out another e-mail today? +[20:10:26] <dilfridge> I thought he wanted to +[20:10:55] <dilfridge> but I didnt get any +[20:11:09] <ulm> I'd much prefer if this was a regular glep +[20:11:18] <blueness> i didn't get any, but i did see the two extra links he had +[20:11:21] <ulm> not some unnumbered draft +[20:11:31] -*- WilliamH agrees with ulm +[20:11:37] <dilfridge> ulm: yes I see your point, but do we have a glep team? +[20:11:44] <blueness> ulm, i agree, we can pass with with the condition that it be glep-ed +[20:12:20] <WilliamH> Are we grandfathering in old keys that do not meet the criteria? +[20:12:22] <ulm> blueness: sounds good +[20:12:33] <dilfridge> could we say, we recommend this be fully formalized and look forward to confirming it? +[20:12:47] <Zero_Chaos> WilliamH: please no +[20:12:53] <WilliamH> dilfridge: sounds good to me. +[20:12:55] <dilfridge> WilliamH: better not +[20:12:58] <ulm> WilliamH: maybe with some longish transition period? +[20:13:11] <dilfridge> long-ish means what? 1 year? +[20:13:23] <ulm> something like that +[20:13:24] <blueness> something like that +[20:13:27] <ulm> :) +[20:13:31] <blueness> heh +[20:13:50] <dilfridge> I'd honestly prefer if the transition period were over the moment we really start the git transition +[20:13:53] <dberkholz> way too long +[20:14:06] <dberkholz> 3 months should be more than enough time for people to read a doc and follow the instructions +[20:14:11] <dilfridge> because then the keys may really be used +[20:14:25] <WilliamH> dberkholz: seems reasonable +[20:14:35] <dilfridge> but I have no idea on the timescale there +[20:14:45] <dilfridge> no objections against 3 months from me +[20:14:48] <Hello71> [21:28:24] <creffett> robbat2: *GLEP hat on* when are you planning to submit the proposal for formal GLEPification? +[20:14:53] <blueness> who's going to enforce it, i bet there will be lots of devs who will be sloppy about it +[20:14:53] <Hello71> [21:28:46] <robbat2> how about in 30 mins when I finish the edits? +[20:14:57] -*- WilliamH grumbles about the git migration taking way too long +[20:15:04] <-- ssuominen (~ssuominen@gentoo/developer/ssuominen) hat das Netzwerk verlassen (Ping timeout: 272 seconds) +[20:15:24] <dberkholz> easy to grumble, harder to do the work =) +[20:15:30] --> ssuominen (~ssuominen@gentoo/developer/ssuominen) hat #gentoo-council betreten +[20:15:31] <dilfridge> Hello71: what's your timezone? i.e. how long ago was that? :) +[20:15:44] <ulm> and what would we do if a dev doesn't update his key in time? +[20:15:46] <Zero_Chaos> dilfridge: last night +[20:15:53] <ulm> revoke commit access? +[20:16:13] <scarabeus> nah just suspend it until he comply +[20:16:26] <dilfridge> ulm: well, in an ideal world commit just wouldnt work because only properly signed commits go in +[20:16:28] <scarabeus> and he gets lost access if he is not active, so that is covered +[20:16:47] <ulm> well, how about enforcing signed commits, in the first place? ;) +[20:17:01] <dilfridge> chicken, egg, chicken, egg, ... +[20:17:09] <blueness> repoman could check the key size +[20:17:31] <blueness> i'm not worried about imposing all the criteria (eg expires in 3 years) but the keysize is important +[20:17:34] <dilfridge> that's actually something the qa team could do too +[20:17:37] -*- dilfridge ducks +[20:17:52] <blueness> dilfridge, i was thinking that but didn't dare say! +[20:18:03] -*- WilliamH isn't really worried about expiration either. +[20:18:03] <dilfridge> anyway +[20:18:13] <dberkholz|web> maybe the "QA lead" should take responsibility =P +[20:18:21] <dilfridge> there are best practices and it's best to follow all of them, +[20:18:49] <dilfridge> and since we are talking about minimum and recommended policies here we should not weaken them unnecessarily +[20:19:05] <dilfridge> i.e. robbat2 knows his stuff +[20:19:26] <blueness> security vs convenience +[20:19:49] <dilfridge> yeah but we're talking not only about our own personal security here +[20:20:05] <ulm> IMHO, getting rid of < 2048 bit RSA is the most important point +[20:20:07] <dilfridge> and to be honest using cvs is the bigger inconvenience :) +[20:20:15] <ulm> I don't care much about the rest +[20:20:31] <ulm> well, maybe except for SHA1 +[20:20:52] <blueness> we should have a deprecation plan, ie tell devs to sign their old 1024 keys with their >=2048RSA/DSA keys +[20:21:29] <dilfridge> not sure if that is needed, since nothing uses the keys so far +[20:21:49] <dilfridge> however, once we start using them, they should adhere to the guidelines +[20:21:56] <blueness> dilfridge, there are devs signing their manifests with keys now +[20:22:08] <dilfridge> blueness: yes but does anything check these sigs? +[20:22:19] <blueness> true +[20:22:23] <ulm> dilfridge: they will be used if robbat2's tree signing gleps are implemented +[20:22:25] <blueness> humans can +[20:22:30] <dilfridge> (I'm doing that too, but it's an exercise in pointlessness) +[20:22:36] <ulm> which I guess will be shortly after git migration +[20:22:58] <dilfridge> ulm: exactly, and that's imho the time when all the keys shoudl follow our new standard +[20:23:16] <ulm> so transition time can be looong :p +[20:23:17] <blueness> dilfridge, yeah sounds reasonabl +[20:24:12] <dilfridge> ok I pinged robbat on infra channel +[20:24:34] <dilfridge> so +[20:24:50] <dilfridge> we don't have a "latest document version" unfortunately +[20:25:03] --> robbat2 (~robbat2@gentoo/developer/robbat2) hat #gentoo-council betreten +[20:25:15] <dilfridge> what shall we do, postpone for next week? +[20:25:15] <blueness> hi robbat2 +[20:25:17] <robbat2> hi, sorry about not updating the GLEP, work stuff +[20:25:24] <dilfridge> hi! +[20:25:36] <blueness> robbat2, we're thinking we should see a final glep before voting +[20:25:53] <robbat2> does this council still do vote-by-email like prior councils? +[20:26:02] <dilfridge> if necessary yes +[20:26:12] <robbat2> and/or do you have any concerns you'd like me to answer now? +[20:26:18] -*- dilfridge no +[20:26:28] -*- WilliamH doesn't think so +[20:26:46] <robbat2> ok, just a merged final version for your seal of approval +[20:27:09] <dilfridge> how does it get a glep number? /me has no idea +[20:27:32] <dberkholz|web> the glep editor assigns one +[20:27:34] <robbat2> i'll have it in a day or two I hope, i just want to review the ENISA paper that dilfridge linked in another channel +[20:27:48] <dberkholz|web> it's in glep 1: http://www.gentoo.org/proj/en/glep/glep-0001.html +[20:28:00] <dilfridge> who's the glep editor? +[20:28:52] <ulm> dilfridge: the project page says antarus, but I don't know if he still has the job +[20:29:16] <robbat2> i'll find somebody to do it +[20:29:22] <dilfridge> ok there's one serious question (robbat2 maybe you can comment), when shall it come into effect, i.e. how long is transition period +[20:29:22] <blueness> robbat2, the only concern i had about the min requirements was the expiration date of 3 years rather than never, i'm afraid people might forget. i know its a good idea, but how bad would it be if people didn't do that? +[20:29:35] <ulm> robbat2: well, just take the next free number ;) +[20:30:18] <robbat2> blueness, the required expiry is there so if they lose their key and didn't make a revocation cert, the key does go away +[20:30:21] <robbat2> in time +[20:30:27] <robbat2> *lose their private key +[20:30:57] <blueness> robbat2, i figured that, but can't the revocation keys be made public? or no? +[20:31:06] <robbat2> no, they can't +[20:31:09] <dilfridge> no +[20:31:14] <Zero_Chaos> robbat2: shouldn't revocation certs be held by a central authority? I mean, what happens when a dev quits and doesn't revoke his own key? +[20:31:22] <blueness> they need a passphrase and the private key to unlock, no? +[20:31:40] <ulm> could we require that devs have either a revocation cert or expiry time? +[20:31:48] <robbat2> no, revocation certs do NOT need any additional auth to use +[20:31:48] <dilfridge> blueness: no, a revoke sig is just a signature, anyone can add it to a key if he has it +[20:32:06] <dberkholz> ulm: that defeats the point of what robbat2 just said +[20:32:11] <robbat2> Zero_Chaos, why would I have to revoke my key if I quit? +[20:32:11] <dberkholz> 19:30 < robbat2 > blueness, the required expiry is there so if they lose their key and didn't make a revocation cert, the key does go away +[20:32:15] <blueness> dilfridge, k i've used one but never looked at it carefully +[20:32:34] <dberkholz> ulm: and frankly it's a lot more likely that someone loses the key *and* the revocation cert +[20:32:40] <robbat2> I want to clarify something here: +[20:32:43] <dilfridge> basically if I had your revocation cert, I could add it to your public key and update your key on the keyserver +[20:32:45] -*- blueness thinks i need to write a nagging script for the community to remind them their key is ab out to expire! +[20:32:46] -*- WilliamH agrees with robbat2 about revoking a key +[20:32:47] <Zero_Chaos> robbat2: so you can't sign things and have them be from a valid gentoo dev? +[20:32:56] <robbat2> this GLEP ONLY covers what GPG keys a dev must have +[20:33:07] <ulm> dberkholz: this can only happen if he's extremely badly organised +[20:33:08] <robbat2> it does NOT cover the trustweb from gentoo(infra) to devs +[20:33:12] <dilfridge> right +[20:33:17] <dilfridge> OK +[20:33:18] <blueness> i gathered that +[20:33:18] <Zero_Chaos> okay, retracted +[20:33:24] <dberkholz> ulm: i would never assume that every dev is well organized +[20:33:27] <chithead> if you want you can set key expiry at 1d and use a new key every day +[20:33:32] <ulm> heh +[20:33:34] <dilfridge> can we agree that having an expiry time is a good thing? +[20:33:37] <robbat2> Zero_Chaos, i can answer your question later in another channel +[20:33:44] <blueness> dilfridge, yes +[20:33:45] <robbat2> but trust me, it's not a problem +[20:34:02] <blueness> i'm convince the goods of the expiration date outweigh the evils +[20:34:03] <dilfridge> ok +[20:34:06] <Hello71> popular CAs limit SSL certificate duration to 5 years atm, no? +[20:34:11] <robbat2> or less +[20:34:26] <dilfridge> so, to finish this I would suggest +[20:34:39] <dilfridge> let's put to a vote +[20:35:11] <robbat2> preliminary approval of the GLEP, pending merging the final edits for later approval +[20:35:19] <dberkholz> sure +[20:35:41] <blueness> works for me +[20:35:43] <dilfridge> 2: we appreciate and approve robbat2's efforts as shown on the mailing list and look forward to signing off the final version of his glep on gpg key policies +[20:36:07] <dilfridge> ^ everyone? +[20:36:10] <rich0> agree - I think the direction is good - just need to nail down just what we approve +[20:36:22] -*- WilliamH yes +[20:36:25] <ulm> could you please post the link to the draft that we preliminary approve? +[20:36:59] <dilfridge> http://thread.gmane.org/gmane.linux.gentoo.project/3155 +[20:37:05] <dilfridge> ok let me reformulate +[20:38:40] <dilfridge> 2A: We appreciate the GLEP draft submitted by robbat2 in above mailing list post, and look forward to approving a final version with additional minor changes merged in. +[20:39:00] <dilfridge> better? +[20:39:12] <robbat2> (weight=0) aye +[20:39:24] <rich0> sure +[20:39:29] <ulm> yep +[20:39:30] -*- dilfridge yes +[20:39:34] <dberkholz> k +[20:39:35] -*- WilliamH yes +[20:39:49] -*- blueness yes +[20:39:51] <ulm> though I still think that 4096 bits are overkill, unless we require everybody to have well-paid armed guards protecting his keys ;) +[20:39:53] <scarabeus> k +[20:40:01] <dilfridge> ok that's 7 yes, unanimous :) +[20:40:28] <dilfridge> next topic +[20:40:37] <dilfridge> (wow, we get to do more than one topic today!) +[20:40:44] <dilfridge> 3. Removing last keyworded package version for a minor arch [5] +[20:40:55] <dilfridge> http://article.gmane.org/gmane.linux.gentoo.project/3110 +[20:41:16] <dberkholz> i'm ready to just vote on that +[20:41:41] <blueness> ditto +[20:41:42] -*- dilfridge reading +[20:41:54] -*- WilliamH reading +[20:42:02] <blueness> key point -> Surely if a stable version can be removed, an unstable one could be... +[20:42:34] <dilfridge> ok as for me we can vote too +[20:42:48] <rich0> hold on - I have serious concerns with that proposal. :) +[20:42:52] -*- rich0 ducks +[20:43:04] -*- WilliamH agrees, if a stable version can be removed, so can an unstable one. +[20:43:22] <dilfridge> do we need to write this out? I suggest voting on the e-mail, I'll paste it into the log later. +[20:43:33] <dilfridge> 3: http://article.gmane.org/gmane.linux.gentoo.project/3110 +[20:43:39] <dilfridge> ^ everyone? +[20:43:46] -*- rich0 yes +[20:43:52] <dberkholz> yes +[20:43:54] -*- dilfridge yes +[20:43:58] -*- WilliamH votes yes +[20:44:01] -*- blueness yes +[20:44:16] -*- ulm yes +[20:44:48] <dilfridge> 6 yes, 1 MIA, motion passed +[20:45:08] <dilfridge> next topic!!! +[20:45:25] <dilfridge> 4. Metastructure: Dead projects [6,7] +[20:45:31] <scarabeus> hum i thought i said yes previously :P +[20:45:37] <scarabeus> so just count that in :) +[20:45:37] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-6.txt +[20:46:00] <dilfridge> none of these three projects evoked any response +[20:46:18] -*- ulm looking at our metastrcture +[20:46:19] <blueness> i'm not sure what to do with them though, do we remove the project pages? +[20:46:43] <dilfridge> "remove" is relative in cvs +[20:47:05] <dilfridge> but yes, I'd suggest so, since they are way outdated +[20:47:40] <rich0> makes sense +[20:47:53] <dilfridge> unless someone suddenly jumps in and says "nononono, it's still alive and (occasionally) kicking" +[20:47:58] <ulm> http://www.gentoo.org/proj/en/gentoo-alt/at/index.xml +[20:48:00] <ulm> http://www.gentoo.org/proj/en/gse/index.xml +[20:48:21] <ulm> http://www.gentoo.org/proj/en/kolab/index.xml +[20:48:42] -*- ulm never even heard of these projects +[20:48:48] <blueness> did neddyseagoon responde for Gentoo Support Everywhere ? +[20:49:07] <dilfridge> nobody responded for any of this +[20:49:16] <dilfridge> but maybe he's not on -project +[20:49:20] <dilfridge> we could ask him +[20:49:28] <scarabeus> i would jus tkill them :) and let them start anew in wiki if they want? +[20:49:31] <blueness> he's the only dev i recognize +[20:49:32] <dberkholz> the alt arch-testers is a subproject, i don't see why that's something the council should care about +[20:49:47] <dilfridge> shrug, ok +[20:50:11] <dberkholz> just ask the alt team to trash it +[20:50:17] <dilfridge> yep +[20:50:43] <dilfridge> general question, is this even something we should bother about? +[20:51:00] -*- dilfridge is a bit "meh" +[20:51:19] <dilfridge> the kolab project looks most certainly dead +[20:51:25] <dilfridge> http://overlays.gentoo.org/proj/kolab/browser/overlay +[20:51:40] <Hello71> take a vote on it ;) +[20:51:52] <blueness> actually scarabeus' idea is not bad +[20:51:55] <dberkholz> dilfridge: yeah, we should care because it's just confusing to people when we document things that don't exist +[20:52:09] <dilfridge> ok +[20:52:15] <blueness> just remove the pages and if no one cares its done, otherwise start over on the wiki +[20:52:26] <dilfridge> let's decide this stuff by voting +[20:52:45] <dilfridge> 4: for all three projects, remove project page and if noone cares it's done +[20:52:52] <dilfridge> everyone? ^ +[20:53:19] -*- blueness yes +[20:53:22] <rich0> Sure - and if anybody ever wants to resurrect them, no objections from us +[20:53:23] -*- rich0 yes +[20:53:27] <scarabeus> yes +[20:53:28] -*- dilfridge yes +[20:54:04] -*- ulm yes +[20:54:13] -*- WilliamH yes +[20:54:22] <dilfridge> that's 5 yes, motion passed +[20:54:31] <dilfridge> 6 yes +[20:54:55] <dilfridge> next topic +[20:55:09] <dilfridge> 5. Metastructure: Reorganization of the project tree [8,9] +[20:55:18] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-7.txt +[20:55:30] <ulm> I'd rather not waste time for reorganising the project tree in proj/en +[20:55:33] <dilfridge> I brought this up, but now I'm not so convinced anymore that it's a good idea +[20:55:49] <ulm> let's wait until we have more complete coverage in the wiki and then do it there +[20:55:55] <dilfridge> yeah +[20:56:07] -*- scarabeus agress +[20:56:10] <scarabeus> ees +[20:56:14] <scarabeus> just convert to wiki and then do it there +[20:56:19] <rich0> Make sense. We can always do alignments little-by-little where it makes sense. +[20:56:19] -*- WilliamH agrees +[20:56:23] <dilfridge> what we could do is ask george if there is still any point in his umbrella project +[20:56:28] <dberkholz> yeah, i think we'll reorganize the website content significantly once we've got stuff in the wiki +[20:56:30] <rich0> If anybody can start a project we'll always have loose nodes. +[20:56:36] <dilfridge> if not we just forget about that during the wiki conversion +[20:57:17] <dilfridge> does anyone want to decide, vote, discuss something still here? +[20:57:32] -*- WilliamH has nothing for this +[20:57:33] <ulm> rich0: yeah, but in the wiki it's easy to adjust things later on +[20:57:53] <ulm> it's flat namespace, with links between projects +[20:58:13] <dilfridge> seems no... with the wiki conversion the namespace becomes flat anyway. +[20:58:14] <ulm> trivial to convert a tlp to a subproject +[20:58:26] <dilfridge> ok +[20:58:36] <dilfridge> then let's conclude this as well. +[20:58:44] <dilfridge> next topic! +[20:58:55] <dilfridge> 6. Modernization/adaption of the Code of Conduct, the return [10] +[20:59:07] <ulm> "the return"? +[20:59:25] <dilfridge> well, yes :) +[20:59:39] <dilfridge> (as in "of the Jedi") +[21:00:01] -*- dilfridge admonishes dilfridge to be more professional during council session +[21:00:04] -*- scarabeus didn't have time to look on it due to opensuse release that hapened today :P +[21:00:19] <scarabeus> so i know dilfridge did some updates there so it is more of his topic now +[21:00:28] <dilfridge> ok let me post the links, just a moment +[21:01:29] <dilfridge> http://dev.gentoo.org/~dilfridge/coc-minimal-new.txt +[21:01:34] <dilfridge> http://dev.gentoo.org/~dilfridge/coc-old.txt +[21:02:20] <dilfridge> the "minimal-new" version is the best I could come up with so far, it's mainly new terms (e.g. ComRel) but also some adaption to realities +[21:02:34] <-- dberkholz|web (0cb05905@gentoo/developer/dberkholz) hat das Netzwerk verlassen (Ping timeout: 250 seconds) +[21:02:36] <dilfridge> maybe we shouldn't decide on this now, but read it and take it home +[21:02:57] -*- WilliamH reads +[21:03:04] <rich0> I don't really care for the last sentence - being invovled isn't a conflict of interest - having a stake in the outcome is a conflict of interest. +[21:03:30] <rich0> But that seems to be a Gentoo thing - no other org that I'm aware of uses the Gentoo definition of conflict of interest. :) +[21:03:31] <dilfridge> the last sentence is actually a weakened version of an old one +[21:03:48] <dilfridge> "To prevent conflicts of interest, Council members may not perform the duties of a proctor." +[21:04:56] <rich0> I'd really prefer that it said something like "Council members and Community Relations members are expected to not participate in cases in which they have a conflict of interest." or something like that. +[21:05:03] <dilfridge> why not +[21:05:27] <rich0> Or better still "Council members and Community Relations members are expected to declare and not participate in cases in which they have a conflict of interest." +[21:06:04] <rich0> However, I won't vote against the improved CoC as it currently stands. +[21:06:26] <rich0> I realize that this is a sensitive area for whatever reason. Not the hill I need to die on... +[21:06:38] <dilfridge> my suggestion: we think about this and vote in the next regular session, and I can also send it to the ml for comments. +[21:06:55] -*- WilliamH agrees with dilfridge +[21:07:05] <dilfridge> then we could actually finish our agenda today! +[21:07:10] <blueness> okay +[21:07:36] <rich0> Sure - we can turn that into its own little thread and then incorporate whatever we settle on. +[21:07:56] <dilfridge> any additional comments? +[21:08:25] <dilfridge> seems not +[21:08:27] <blueness> nope +[21:08:31] <dilfridge> good +[21:08:44] <dilfridge> 7. Revival of archives.gentoo.org [11] +[21:08:51] <scarabeus> what we can do there? +[21:09:00] <scarabeus> it is mostly up to infra +[21:09:01] <dilfridge> I don't want to push or order anyone around here +[21:09:19] <dilfridge> my point was just to suggest that we say +[21:09:21] <blueness> dilfridge, just ask infra what's up with the archive and what their ideas are +[21:09:46] <dilfridge> "It was a good idea and it would be great to have it back at some point in the future." +[21:09:48] <rich0> Agree - unless we're going to beg the Trustees to let us hire somebody to do it or something, all we can say is "yeah, sounds like a good idea...duh..." :) +[21:09:49] <robbat2> that was asked in our channel already, i thought by one of you +[21:10:03] <robbat2> the problem is just the web frontend being really broken +[21:10:04] <ulm> dilfridge: maybe cc council to the relevant bug? +[21:10:15] <robbat2> some of the mhonarc customizations got lost in the sands of time +[21:10:20] <dilfridge> ulm: can do +[21:10:31] <ulm> bug 424647 +[21:10:33] <willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken URLs for e.g. gentoo-dev-announce and others"; Gentoo Infrastructure, Other; CONF; darkside:infra-bugs +[21:10:35] <robbat2> and we'd love somebody to come forward with another solution, because mhonarc was reaching scalability limits anyway +[21:11:05] --> dberkholz|mob (~dberkholz@gentoo/developer/dberkholz) hat #gentoo-council betreten +[21:11:16] <ulm> robbat2: scalability because of increased traffic? +[21:11:20] <ulm> or archive size? +[21:11:22] <dilfridge> I remember that someone was already interested to look at it but I dont remember who it was +[21:11:32] <robbat2> archive size, increased list traffic +[21:12:08] <rich0> Isn't there an out-of-the-box solution for email archiving? There has to be... +[21:12:11] <robbat2> at least one part of mhonarc was O(n) where n is the number of messages to the list so far; so growing worse at each pass +[21:12:19] <dilfridge> :( +[21:12:26] <robbat2> rich0, mhonarc is one of those solutions +[21:12:40] <blueness> can't we "outsource" this ie just use gmane +[21:12:57] <rich0> Why is gmane missing emails anyway? +[21:12:57] <ulm> blueness: gmane loses some messages +[21:13:01] <robbat2> so one proposal was gmane, another was run the gmane code ourselves +[21:13:04] <blueness> have links up to the relavent gmane lists +[21:13:05] <dilfridge> well for some weird reason gmane lost most +[21:13:12] <dilfridge> of the proposals for last session +[21:13:16] <blueness> wierd +[21:13:45] <robbat2> it's probably a 60-80-hour project for whomever wants to take it on +[21:13:57] <ulm> also importing an existing archive into gmane is a PITA +[21:14:36] <ulm> last time I asked for it, they screwed up message order, and then refused to fix it +[21:14:57] <dilfridge> does anyone see a need for a vote of whatever kind here? I don't really, I think the difficulty is clear +[21:16:07] -*- WilliamH doesn't see the need for a vote either +[21:16:45] <blueness> nah no need to vote here +[21:16:55] <dilfridge> ok +[21:17:02] <ulm> don't know what we would vote on +[21:17:15] <dilfridge> then, lets continue +[21:17:26] <dilfridge> 8. Open bugs with council involvement +[21:17:26] <dilfridge> * Bug 477030 - Missing summary for 20130611 council meeting [12] +[21:17:27] <willikins> dilfridge: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council +[21:17:40] <dilfridge> any news here? :) +[21:18:02] <ulm> scarabeus: you wanted to ping betelgeuse? +[21:18:05] <dilfridge> btw there is another summary missing, my fault, it's done and will be commited once I get around to it +[21:19:08] <dilfridge> ook no news here. wash, rinse, repeat, next meeting. +[21:19:14] <blueness> lol yeah +[21:19:17] <ulm> *sigh* +[21:19:26] <dilfridge> which brings us to +[21:19:33] <dilfridge> 9. Open floor +[21:20:22] <dilfridge> anyone? +[21:20:22] <blueness> every, i need to leave, but it looks like we're done anyhow +[21:20:28] <blueness> good meeting! +[21:21:22] <dilfridge> seems like there are no voices on the open floor +[21:21:29] <-- graaff (~graaff@gentoo/developer/graaff) hat das Netzwerk verlassen (Quit: Leaving) +[21:21:31] <dilfridge> with that +[21:21:34] <dilfridge> I'd say +[21:21:39] <TomWij> There's some minor stuff that got outdated (new project to be filed on wiki, authors not marked as retired, ...) or isn't clearly documented (KEYWORD="" and/or package.mask), but I haven't came around to writing patches yet; so it's gonna be for another meeting. +[21:21:49] <dilfridge> ok +[21:22:16] <dilfridge> sounds good +[21:22:26] <dilfridge> anyone else? +[21:22:55] <dilfridge> nope +[21:23:27] <dilfridge> meeting closed; next one is 10 December |