path: root/meeting-logs/20131119.txt

[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