add meeting log

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