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