diff options
Diffstat (limited to 'meeting-logs')
| -rw-r--r-- | meeting-logs/20161211-summary.txt | 76 | ||||
| -rw-r--r-- | meeting-logs/20161211.txt | 563 | ||||
| -rw-r--r-- | meeting-logs/20161211.txt.asc | 16 |
3 files changed, 655 insertions, 0 deletions
diff --git a/meeting-logs/20161211-summary.txt b/meeting-logs/20161211-summary.txt new file mode 100644 index 0000000..4e92d5f --- /dev/null +++ b/meeting-logs/20161211-summary.txt @@ -0,0 +1,76 @@ +Summary of Gentoo council meeting 11 December 2016 + +Agenda +====== + +1) Roll call +2) Dropping of IA-64/SPARC Stable support +3) Gentoo-council mailing list, -project list moderation (also, purpose of -project) +4) Open floor + + +Roll call +========= +Present: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + + +Dropping of IA-64/SPARC Stable support +====================================== + +The general discussion was around the distinction between security +support and stable support, and the general sense was that stable +support should probably be tabled and addressed by the stable working +group. It was believed that addressing security support for these archs +would address the original concern. + +"The council defers to the security team, but is supportive of dropping +security support for sparc if it is unable to generally meet the +security team timelines." + +yes: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + + +Gentoo-council mailing list, -project list moderation (also, purpose of -project) +================================================================================= + +"The council would like the community to consider mailing list +discipline when posting to the various MLs of the Gentoo community. This +includes, but is not limited to, thread discipline and a consideration +of whether a new post adds value to the discussion at hand when posting +in order to ensure a good signal to noise ratio." + +"Messages should be inline quotation and cropped to the relevant +quotation needed for context in order to improve readability" + +yes: blueness, dilfridge, jlec, k_f, rich0, ulm abstain: williamh + +It was noted that sometimes top-posting can be appropriate, and these +aren't completely hard rules. + + + +Open floor +========== + +prometheanfire brought up whether it would be beneficial to have +Council/Trustee members attend each other's meetings to provide more +immediate feedback on questions. The sense was that this could be +useful, but probably should be based on specific agenda topics/etc and +requested in advance vs being a general practice. + +prometheanfire brought up his proposal for having a single governing +board at: +https://docs.google.com/document/d/10xzPUREMzZllT7dLs85JjMvlymEY9wWzYPRCnTZIsfI/edit?usp=sharing +He is looking for comments from both Council and Trustees. It was +suggested that this be taken to the lists, but there was general +interest in participation. + +rich0 mentioned that he would be working on a comrel glep, but he'll +take the details to the lists/etc as time was running long. Anybody who +is interested can participate, and prometheanfire and neddyseagoon both +registered interest. + +dilgridge brought up Software in the Public Interest and asked the +Trustees to take another look at them. It was suggested that this might +be worked into the single board proposal in some way since it is a +metastructure change. diff --git a/meeting-logs/20161211.txt b/meeting-logs/20161211.txt new file mode 100644 index 0000000..253cc97 --- /dev/null +++ b/meeting-logs/20161211.txt @@ -0,0 +1,563 @@ +[14:00:36] <rich0> Ok, time to start. +[14:00:55] <rich0> Roll call: dilfridge, blueness_, jlec, K_F, ulm, WilliamH +[14:00:58] -*- rich0 is here +[14:01:00] -*- dilfridge here +[14:01:01] -*- blueness_ here +[14:01:05] -*- jlec here +[14:01:14] -*- K_F here +[14:01:31] -*- WilliamH here +[14:01:40] -*- ulm here +[14:01:45] <rich0> Excellent! +[14:01:48] <prometheanfire> here +[14:01:49] <rich0> Agenda is at: https://archives.gentoo.org/gentoo-project/message/44e9968f87afff0006ccc2d9a39a64ee +[14:02:11] <rich0> Ok, first topic is Dropping of IA-64/SPARC Stable support +[14:02:16] <rich0> https://archives.gentoo.org/gentoo-project/message/139ba32bbecd46c5bad53dbd22138f24 +[14:02:42] <dilfridge> did anone from these arch teams respond there? +[14:02:46] <rich0> Anybody want to offer any comments? +[14:02:49] <dilfridge> !proj ia64 +[14:02:50] <willikins> dilfridge: (ia64@gentoo.org) ago, hattya, jmorgan, vapier, zlogene +[14:02:55] <dilfridge> !proj sparc +[14:02:55] <willikins> dilfridge: (sparc@gentoo.org) ago, jer, jmorgan, pacho, vapier, xmw, zlogene +[14:02:59] <K_F> dilfridge: I haven't seen any official response from arch teams on the issue +[14:03:08] <K_F> I can offer some insight from Security Project perspective +[14:03:08] <rich0> ago did reply to both, but not really "officially" per se +[14:03:13] <rich0> K_F: please +[14:03:59] <K_F> keeping the list of stable arches and security supported arches in sync is a benefit, and it eases communication as well as workflow (in particular with regards to cleanup) +[14:04:17] <K_F> but it isn't strictly needed, and has been deviated from in the past +[14:04:34] <K_F> the end result is a larger number of bugs waiting for cleanup, but we can release GLSAs quicker as there isn't support for it +[14:04:58] <rich0> can or can't? +[14:05:02] <K_F> can +[14:05:09] <K_F> but the bug stays open afterwards for cleanup +[14:05:31] <rich0> So, you're suggesting sending out the notice, but not removing the affected package. +[14:05:32] <blueness_> K_F: i’m okay with dropping sparc and ia64 to ~arch for security reasons but not ppc/ppc64, let me explain why +[14:05:46] <K_F> rich0: yes, that is current practice +[14:05:46] <dilfridge> could you explain what happens to a sec-stabilization bug, if the supported arches are all stable but other stable arches still wait for stabilization? +[14:05:49] <blueness_> (or ai’ll wait) +[14:06:04] <rich0> dilfridge: first +[14:06:11] <rich0> blueness_: second :) (yours is longer) +[14:06:21] <K_F> rich0: but if security supported, GLSA needs to wait for stabilization from the teams.. if not security supported it becomes a matter of waiting for cleanup only +[14:06:50] <K_F> dilfridge: GLSA goes out one the security stabilizated packages are done.. bug remains open in [cleanup] state until it is gone +[14:06:59] <K_F> which will , on expectational basis, take longer time +[14:07:08] <K_F> but at least it doesn't stop GLSA release +[14:07:21] <dilfridge> ok +[14:07:23] <rich0> Ok, blueness_? +[14:07:46] <blueness_> the problem with dropping from stable to dev is building stages +[14:07:52] <K_F> I should also point out that IA64 is not a security supported arch per policies today, but is so by convention +[14:07:58] <blueness_> so i don’t build ia64 or sparc stages, but ppc/ppc64 i do +[14:08:08] <K_F> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html , Here is the list of currently supported architectures: alpha, amd64, hppa, pcc, ppc64, sparc, x86. +[14:08:15] <K_F> so the real question is sparc +[14:08:20] <K_F> from that point of view +[14:08:22] <blueness_> so i don’t care too much if not @system packages fall behind, even for security reasons +[14:09:12] <rich0> blueness_: this came up before a while back I believe. The goal is to have a core of stable keyworded packages for reliable stage generation, and as a springboard? +[14:09:43] <K_F> blueness_: I dont believe anyone has proposed ppc/ppc64 being dropped at this stage? +[14:09:55] <WilliamH> No, they haven't. +[14:10:09] <dilfridge> No +[14:10:25] <jlec> we should keep them stable if possible +[14:10:29] <rich0> So, here is my thought: I think it is important that what we call security supported be in fact security supported. +[14:10:32] <blueness_> i’d rather non-@system packages be dropped to ~arch than the whole profile be dropped to ~arch just to take care of some security issue in some marginal package +[14:10:34] <blueness_> rich0: correct +[14:10:35] <blueness_> K_F: yes reread aaron’s email +[14:10:35] <blueness_> point 4 https://archives.gentoo.org/gentoo-project/message/139ba32bbecd46c5bad53dbd22138f24 +[14:10:40] <dilfridge> (but it's not really looking nice either, see http://www.akhuettel.de/gentoo-bugs/ ... I dont have any plots for ia64 and sparc though.) +[14:11:00] <K_F> blueness_: right, thats not up for today :) +[14:11:27] <rich0> So, if an arch generally can't keep up with security bugs, they should lose security support status (so that users are informed of the reality of their situation). +[14:11:36] <blueness_> K_F: i’d like to think of an alternative if it gets there, like dropping individual packages to ~arch +[14:11:41] <rich0> That is of course different from stable support. +[14:11:55] <blueness_> rich0: that works too +[14:12:13] <rich0> blueness_: that is the whole business that k_f / kensington team is trying to deal with, it is painful to fix all those keywords +[14:12:30] <blueness_> rich0: yeah, i was supposed to help out too but real life +[14:12:33] <WilliamH> blueness_: that could happen right now. Arch teams could just put a note on a bug that they don't want x package stable on their arches. +[14:12:36] <blueness_> but i’m very keen on what we do there +[14:12:48] <rich0> I think we have already given the go-ahead to drop stable keywords individually/etc after so many days, but the reality is that nobody wants to deal with it +[14:13:18] <WilliamH> rich0: we've only given the go-ahead on certain arches, not globally. +[14:13:31] <rich0> Anybody remember which ones offhand? +[14:13:36] <WilliamH> rich0: but, yes, no one wants to do it. +[14:13:40] <rich0> (or at least ia64/sparc?) +[14:13:59] <kensington> according to qa, it can be done for any arch +[14:13:59] <kensington> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs +[14:14:00] <WilliamH> rich0: we get yelled at if we break the deptree, which I thought was up to the arches to fix if we drop them. +[14:14:14] <K_F> for the particular request, unless someone else wants to drop it .. from security perspective I propose we just phrase a "if security want to drop stable support for lagging arches such as sparc, they can do so on their own decision" kind of thing +[14:14:40] <rich0> I'm getting a sense that most here support dropping security support for the archs, but stable support needs more care? +[14:14:41] <K_F> then I can bring that up in security team for a vote +[14:14:58] <K_F> rich0: stable support needs more care, but we can handle that in wg-stable +[14:15:10] <WilliamH> kensington: the issue is, say openrc, if I yank an older version because some arches haven't stabled newer ones, it breaks their stages +[14:15:16] <rich0> My sense is that dropping security support only addresses the original concern? +[14:15:32] <K_F> rich0: it does +[14:15:43] <WilliamH> kensington: am I allowed to break their stages because they can't keep up? +[14:15:55] <K_F> WilliamH: no +[14:16:05] <kensington> WilliamH: certainly this rule doesn't work for every type of package +[14:16:08] <rich0> K_F: do you suggest that we take action, or do you think the security team can deal with this? +[14:16:29] <K_F> rich0: I'd like a note that council does not oppose sparc losing stable support +[14:16:30] <WilliamH> kensington: so why can't they prioritize stabilizing those packages? +[14:16:37] <K_F> rich0: ehrm, security support +[14:16:41] <K_F> now I'm confusing myself.. +[14:16:48] <rich0> How about ia64? +[14:16:48] <K_F> as it has historically been used on servers etc +[14:16:53] <WilliamH> kensington: I think if an arch can't stabilize @system packages they shouldn't have a stable profile +[14:16:57] <K_F> ia64 isn't formally security supported +[14:17:02] <rich0> ok +[14:17:06] <K_F> but fine by me to add it in for cause +[14:17:40] <rich0> I'm fine with that, and if the arch team wants to be considered security supported they have to keep up. IMO it is just "false advertising" to call it supported if bugs stay open forever. Users should at least know what they're getting into. +[14:17:47] <dilfridge> K_F: "stable support" or "security support"? +[14:17:50] <rich0> And changing back to security supported in the future is easy. +[14:17:54] <K_F> dilfridge: security support +[14:18:54] <rich0> So, how about this wording: "The council defers to the security team until next month, but is supportive of dropping security support for sparc if it is unable to generally meet the security team timelines." +[14:19:07] <rich0> Any tweaks? +[14:19:17] <K_F> I'm not sure there needs to be a timeline? +[14:19:27] <K_F> s/until next month// +[14:19:44] <rich0> I'm fine either way, we could just note that if it is still an issue we may revisit it. +[14:20:19] <rich0> "The council defers to the security team, but is supportive of dropping security support for sparc if it is unable to generally meet the security team timelines." +[14:20:28] <dilfridge> ++ +[14:20:29] <K_F> lgtm +[14:20:31] <blueness_> lgtm +[14:20:33] <rich0> ok, vote: +[14:20:34] -*- rich0 yes +[14:20:37] -*- K_F aye +[14:20:37] -*- blueness_ yes +[14:20:37] -*- WilliamH yes +[14:20:41] -*- dilfridge yes +[14:20:43] -*- ulm yes +[14:21:07] <rich0> jlec: ? +[14:21:08] -*- jlec yes +[14:21:13] <rich0> ok, passed 7-0 +[14:21:23] <rich0> Anything else on that one? +[14:21:34] <K_F> not from me +[14:21:38] <rich0> Next topic: Gentoo-council mailing list, -project list moderation (also, purpose of -project) +[14:22:31] <dilfridge> well, that kinda fixed itself +[14:22:53] <ulm> I don't think that it's fixed +[14:22:56] <K_F> well, the specific issue did, but a generic discussion can be in order still +[14:22:58] <rich0> ulm: you raised the topic. Do you want to say anything? +[14:23:13] <ulm> council items are drowned in the noise in -project +[14:23:35] <ulm> therefore the suggestion to revive the dedicated mailing list +[14:24:10] <rich0> So, my sense is that most of the stuff on -project was council-relevant (to the extent that it was on-topic at all), but it was noisy as far as how the discussions went +[14:24:10] <prometheanfire> a council specific list might be good, can be moderated +[14:24:37] <ulm> the second reason is that part of council topics are of a technical nature +[14:24:52] <ulm> therefore not really appropriate for -project +[14:24:57] <WilliamH> The noise level on -prooject was so high for a while that it became a huge timesink. +[14:25:03] <WilliamH> -project * +[14:25:27] <rich0> IMO the issues on -project are a bit orthogonal to where we discuss council topics. +[14:25:51] <rich0> If -project is broken (if), then that should be fixed, rather than just trying to hide from the list. +[14:26:06] <K_F> rich0: I believe I agree with that sentiment +[14:26:18] <rich0> I think the technical vs non-technical issue is potentially valid. +[14:26:25] <ulm> rich0: there may be high traffic even without the list being broken +[14:26:28] <rich0> But, I'm not sure I like the idea entirely. +[14:26:34] <dilfridge> the problem with -project is, it's hard to define "on-topic" there +[14:26:43] <WilliamH> -project is supposed to be non-technical right? +[14:26:47] <dilfridge> right +[14:26:49] <jlec> I think we should try to fit in the council items in -project and for technical in -dev. +[14:26:49] <rich0> dilfridge: indeed, that was also a topic Shentino brought up :) +[14:26:53] <WilliamH> -dev is technical ... +[14:27:02] <K_F> I believe a valid conern is also archiving reasons, having a specific list makes it easier to find decisions and discussions etc +[14:27:15] <rich0> So, how would it work if we did it? +[14:27:15] <K_F> irrespective of technical vs non-technical concern +[14:27:16] <jlec> rich0: you are right, if there is a problem we should fix that. +[14:27:29] <rich0> Have people repeat their key points or reference them in -council once a topic goes before council? +[14:27:35] <K_F> on the other hand, having contributions from a broader contributor base to discussions is a concern, will a specific list have that participation? +[14:27:58] <rich0> I think the reality is that most issues are goign to start on -dev or -project before becoming council items in general. +[14:28:01] <jlec> rich0: that would work, or we just use the wiki +[14:28:06] <K_F> and are devs actively avoiding -project due to volume, so that last point is moot? +[14:28:22] <rich0> so, if we do something with the wiki, where does a -council list fit into it? +[14:28:26] <Shentino> That is why I wanted it "officially" clarified as to the purpose of g-project ML +[14:28:52] <jlec> rich0: no -council. discussion on the existing lsits and summary in wiki +[14:28:53] <WilliamH> Shentino: the purpos of -project is non-technical discussions about Gentoo. +[14:28:59] <WilliamH> purpose * +[14:29:00] <jlec> like you suggested for -council +[14:29:05] <rich0> So, if devs are avoiding -project because the topics don't interest them that is one thing. If it is purely volume/noise then I think that is a different matter. +[14:29:30] <jlec> the noise is the problem, not the volume +[14:29:33] <rich0> WilliamH: non-technical stuff about the distro, but not foundation matters (for which we have -nfp). +[14:29:39] <rich0> And of course we have tons of dedicated project lists. +[14:29:51] <WilliamH> rich0: Right. +[14:29:52] <rich0> -project is basically a place to talk about Gentoo topics that don't fit elsewhere, IMO +[14:30:08] <dilfridge> rich0: that definition is not helpful +[14:30:20] <dilfridge> because then nothing is offtopic +[14:30:27] <ulm> rich0: yeah, and it is sort of strange that council topics would be discussed there +[14:30:28] <robbat2> perhaps changing the official description would also help; it's presently "For the discussion of non-technical matters in Gentoo +[14:30:42] <ulm> especially if many projects have their dedicated lists +[14:30:49] <dilfridge> hmm +[14:30:49] <ulm> and the foundation has -nfp +[14:31:10] <rich0> Well, the original purpose of -project was to get that stuff off of -dev +[14:31:19] <rich0> And make -dev much more purely technical. In that it was mostly a success. +[14:32:10] <dilfridge> would moving the council agenda/topic stuff to -dev help? then we can say "it's technical, or it's a council issue", which is somehow delineated +[14:32:18] <K_F> of course, agenda would still go to dev-announce, so devs are notified +[14:32:20] <rich0> So, if we made a -council list and it was moderated, what would be the rules/etc? +[14:32:36] <prometheanfire> dilfridge: I think crossposting it would be wise +[14:32:47] <rich0> Maybe only discussion of proposed agenda items, or business being brought before the council? +[14:32:51] <K_F> rich0: imho @gentoo.org should go through directly anyways +[14:33:03] <ulm> yes, no moderation for @gentoo.org please +[14:33:05] <rich0> K_F: sure, but that is more about how it is moderated/etc +[14:33:06] <K_F> so moderation would be for external contributors, I'd say the requirement is that it is on-topic +[14:33:19] <rich0> Hence the need to define the topic +[14:33:38] <jlec> perhaps we should introduce -gentoo-rant and come back to saome sane -project & -dev +[14:33:42] <rich0> (I'm brining up -council first because i think it is simpler to define than -project, and whether we go with it affects teh latter) +[14:33:44] <K_F> well, for council that is likely easy enough.. either a direct response to call for agenda, or on-topic discussion for it +[14:34:03] <robbat2> for questions of new list moderation; the key question I have from the infra perspective: who are the moderators? (infra is not taking on that role) +[14:34:10] <rich0> So, in general I'm not really a fan of solving noise problems by defining a /dev/null list and having all the noise go there +[14:34:18] <dilfridge> right +[14:34:20] <K_F> robbat2: could solve that by council being moderators +[14:34:27] <dilfridge> we can't talk about moderation without having moderators +[14:34:48] <dilfridge> only for -council. for -project that's a nutjob. +[14:34:51] <floppym> Heh, that sounds like an excellent use of council members time. +[14:34:54] <K_F> yes, for -council +[14:35:29] <rich0> Here is the thing, to the extent that stuff going before council does get moderated, people are going to tend to just post it elsewhere, resulting in noise. +[14:35:40] <mpagano> gentoo-complaints +[14:35:44] <rich0> Because their goal is to get heard, and obviously the topic is of some importance if somebody brought it up to council. +[14:35:57] <K_F> rich0: that is a concern, indeed +[14:36:15] <rich0> I don't really have an issue with moderation if the goal is to let everybody say any particular thing once and then cut down on repitition or last-word-itis. +[14:36:35] <prometheanfire> a mechanism for to tell someone that they need to distil their topic to be consumable would be helful +[14:36:38] <WilliamH> Yes, if -council was moderated, we would have to be quick on either approving messages or not. +[14:36:43] <K_F> another point is, as long as the topics are semi on-topic, people can ignore threads or set up discard rules in sieve etc +[14:36:57] <ulm> the old -council list wasn't moderated and it worked well enough +[14:37:02] <K_F> do we really need a top-level moderation of things that people can decide on themselves and MUAs should support? +[14:37:09] <rich0> Thread discipline would be another benefit of moderation. +[14:37:14] <ulm> so I wonder if we need moderation at all +[14:37:27] <WilliamH> Yeah, I'm not a big fan of moderation I don't think. +[14:37:45] <jlec> I don't think moderation is good. Same as I don't think bans are good. Communities need to be self healing +[14:37:49] <rich0> So, here is the thing, 4 months ago, were any of us considering this a problem that needed a solution? +[14:37:57] <jlec> Although that is easier said than done +[14:38:01] <K_F> can't speak for others, but not me +[14:38:06] <prometheanfire> I'd rather not have moderation +[14:38:09] <rich0> It seems like an overly involved solution to a specific problem. +[14:38:13] <dilfridge> no, 4 months ago not +[14:38:28] <rich0> But the technical vs non-technical concern would have been just as valid back then. +[14:38:46] <K_F> rich0: to the extent that council is only involved in technical matters +[14:38:47] <rich0> And my sense is that it wasn't such a big deal except for the fact that every topic was getting derailed. +[14:38:50] <ulm> rich0: I never liked the join of -council with -project +[14:39:01] <prometheanfire> perhaps be quicker on timeouts? +[14:39:09] <prometheanfire> that'd be a question for dilfridge +[14:39:10] <rich0> K_F: i've never considered the council to be only involved in technical matter +[14:39:21] <K_F> rich0: which is an argument for -project being OK +[14:39:27] <rich0> IMO thread discipline is probably the biggest recent issue. +[14:39:38] <K_F> I agree, thread dicipline, and posting dicipline in general +[14:39:43] <rich0> If we want to have a thread about why <xyz> isn't well-supproted then fine. +[14:39:45] <K_F> to reduce overall volume of messages to useful +[14:39:46] <WilliamH> rich0: Yes, I agree. +[14:40:01] <rich0> However, every time any issue comes up, mention that if we only fixed this then <xyz> would be more supproted gets tiresome. +[14:40:08] <K_F> "if you're not contributing anything useful to the discussion, please consider not posting the message" +[14:40:34] <WilliamH> K_F: heh +[14:40:45] <dilfridge> well, 1) as I said, it's hard to draw a line on -project... 2) nobody wants to become the "big censor", so waiting until everyone else is annoyed becomes a strategy +[14:40:53] <K_F> "gentoo-project should be a discussion forum for topics relating to Gentoo. Consider the signal to noise ration when you wonder whether you should post something or not" +[14:41:20] <rich0> Gotta ration that signal, wouldn't want too much of it. :) +[14:41:40] <WilliamH> K_F: sure, but the most recent noise supposedly was Gentoo related... +[14:41:46] <dilfridge> You forgot about the IRS, and the Illuminati. +[14:42:02] <rich0> well, that was ok since it was on -dev :) +[14:42:03] <K_F> WilliamH: I'm not sure how many of the posts in question contributed to the discussion... +[14:42:04] <WilliamH> dilfridge: lol +[14:42:38] <WilliamH> K_F: sure, but the poster sure thought they did, lol. +[14:43:02] <rich0> I really don't think this is a long-term problem, and I'm concerned the cure is worse than the disease. +[14:43:16] <rich0> If it is long-term then I don't think just reviving a list is the fix anyway. +[14:43:21] <K_F> in any case, in general I don't want council to be a separate entity away from the community. a separate ML might make sense for archiving purposes and lookups, but otoh we have meeting logs and agendas that solves most of it +[14:43:41] <rich0> IMO the summaries/agendas already solve that problem. +[14:43:45] <WilliamH> Wasn't there supposed to be a decisions document also? +[14:43:45] <ulm> K_F: it is not "away from the community" +[14:43:53] <prometheanfire> seperating the discussion from the official requests may still be helpful +[14:43:57] <ulm> it is just a means to categorise the traffic +[14:44:09] <WilliamH> prometheanfire: Yeah, that's true too. +[14:44:30] <rich0> prometheanfire: that could be accomplished via thread discipline. Get people used to posting the topic on the agenda thread, and then starting a discussion thread for it +[14:44:31] <WilliamH> That would mean that calls for agenda items etc would go on council and g-d-a +[14:44:47] <prometheanfire> rich0: good luck :P +[14:44:56] <dilfridge> I think that the -project troubles have been very specific, and that there is a simple way to make them disappear, just that of course there's a downside of that (for someone) as well. +[14:45:06] <rich0> Yeah, I will admit that making sure I got all the agenda topics was painful due to that thread going crazy. +[14:45:28] <K_F> rich0: that is only an issue if the threads aren't OK +[14:45:37] <K_F> and the agenda threads weren't overly bad +[14:45:58] <rich0> Again, I'd rather work on thread discipline because that is something that benefits everybody everywhere. +[14:46:06] <rich0> And it seems like the "light handed" solution. +[14:46:06] <K_F> yup +[14:46:09] <blueness_> okay i wasn’t certain about this issue but from the above discussion, i think a -council list for council business open to the community is the say to go, not moderated +[14:46:29] <blueness_> s/say/way +[14:46:42] <rich0> Any other thoughts? I'm thinking maybe a quick poll for support for a new list vs keeping the same ones, and then we can worry about wording? +[14:46:54] <blueness_> yeah, let’s do that +[14:47:12] <rich0> Ok, please post whether you prefer a -council vs just sticking with -dev/-project? +[14:47:17] -*- rich0 -project/dev +[14:47:28] -*- blueness_ -council +[14:47:38] -*- ulm -council, obviously +[14:47:48] -*- jlec -project/dev +[14:48:08] -*- K_F -project/dev +[14:48:29] <rich0> dilfridge, WilliamH ? +[14:48:42] -*- dilfridge project/dev +[14:49:06] -*- WilliamH -council mostly because of the volume on -project +[14:49:25] <rich0> Ok, that is a majority for keeping things as they are. Do we need to actually vote on something specific? +[14:49:46] <rich0> I can record the general preference in the summary either way. +[14:49:49] <K_F> we could vote on an announcement for thread and posting dicipline +[14:49:52] <ulm> so then in future please explicitly cc me for the stuff on -project +[14:49:53] <WilliamH> The problem is, how do we get thread discipline to work? +[14:50:10] <ulm> because other wise I may miss something important +[14:50:14] <WilliamH> When you reply to a message, changing the subject alone doesn't start a new thread. +[14:50:18] <rich0> Well, if we can't I don't mind revisiting the problem, but that is going to be an issue anywhere. +[14:50:23] <ulm> *otherwise +[14:51:08] <WilliamH> People do a lot of this on threads: +[14:51:13] <WilliamH> re: foo was bar +[14:51:20] <WilliamH> but that doesn't break the thread +[14:51:31] <rich0> How about something like "The council would prefer to encourage the community to improve thread discipline and avoidance of repetition on the current lists before changing how we discuss agenda topics. This will be the topic of a list post." +[14:52:05] <rich0> WilliamH: suggest that MUA-101 be a topic we bring up, but that is like getting people to bottom-post. All you can do is keep pointing it out. +[14:52:08] <ulm> rich0: that's mostly a no-op because the problematic won't care about it +[14:52:29] <rich0> ulm: well, I'm all for specific solutions to specific problems. +[14:52:33] -*- WilliamH also hates the reply-to munging we do but that's a separate topic I guess +[14:53:04] -*- rich0 nominates WilliamH for the email etiquette indoctrination working group +[14:53:10] <WilliamH> heh +[14:53:13] <prometheanfire> https://www.wikiwand.com/en/Posting_style#/Bottom-posting :P +[14:53:37] <rich0> In any case, do we want to vote on the proposal I put out there, or tweak it? +[14:53:42] <K_F> bottom posting is one thing, but people need to trim their quotes for sure +[14:53:45] <rich0> I get that it isn't the solution everybody wants. +[14:54:11] <K_F> rich0: so to get it straight, that implies a discussion topic on email etiquette on -project, right? +[14:54:12] -*- rich0 nominates K_F for vice-chair of the email working group +[14:54:22] <rich0> Apparently. +[14:54:41] <dilfridge> ok so we want to solve the off-topic posting problem by bikeshedding +[14:54:42] <K_F> rich0: https://blog.sumptuouscapital.com/2016/01/email-are-you-writing-emails-in-a-proper-etiquette/ < I've tried and failed :| +[14:55:14] -*- WilliamH isn't happy with that solution +[14:55:23] <WilliamH> we end up with endless bikesheds already +[14:55:26] <rich0> So, here's my thought, unless we actually impose moderation then the noise problem doesn't go away just because we create a new list to put the noise on. +[14:55:52] <K_F> but we can make a statement on how we want it +[14:55:55] <rich0> All the threads on -project will just move to -council, since their purpose was to get attention/etc. +[14:56:15] <ulm> rich0: where they would be clearly off-topic however +[14:56:27] <WilliamH> K_F: sure, but what can we really put behind that statement -- when people disregard it? +[14:56:32] <rich0> People aren't dumb. If you tell them to go post on some list nobody reads, they won't fall for it. +[14:56:33] <ulm> giving us some handle for measures against them +[14:56:48] <K_F> WilliamH: if bad enough, could ban it if it goes against the stated description +[14:57:00] <dilfridge> so how do we define the topic of -project ? +[14:57:09] <K_F> dilfridge: I believe it comes back to that +[14:57:10] <rich0> The thing is, that much of the stuff on -project was relevant to council decisiosn (not necessarily ones in the very next meeting, but certainly longer-term). +[14:57:23] <jlec> How do peers like debian and so handle this? +[14:57:25] <rich0> I don't care for HOW the posts were done, but I can't say that the topics themselves weren't relevant. +[14:57:32] <jlec> I assume they have the same problems. +[14:57:33] <K_F> rich0: I'd tend to agree +[14:57:57] <rich0> Now, if we want to have -council as a focused list for only topics in the very next council meeting, that might be a value-add. +[14:58:12] <rich0> Ie, no discussing topics that aren't on a call for agenda items. +[14:58:24] <WilliamH> The way -project is defined we can't say that the noise was off-topic. +[14:58:31] <rich0> And then longer-term stuff stays on -dev or -project. +[14:59:22] <WilliamH> Maybe it wasn't off-topic, but imo there was a major behavioural issue involved. +[14:59:23] <rich0> Honestly, though, I don't see council members being able to avoid these general topics, since the topics themselves are important, even if we don't all agree with every opinion presented. +[14:59:40] <rich0> WilliamH: sure, and you don't solve people problems with list topics +[14:59:55] <WilliamH> rich0: No, you don't, I agree there. +[15:00:42] <rich0> So, where do we go from here? I could get behind a -council if the intent is to have a place for more razor-focus on specific action items for the next meeting, but I do have concerns that it could be perceived as isolationist. Personally I'd still participate on -project. +[15:01:12] <rich0> If we just maintain the status quo, then do we just drop this for a month and move on? I'm not sensing excitement over any alternatives besides noop. +[15:01:32] <rich0> And those of us who care can tilt at the email-101 windmills regardless. +[15:01:39] <WilliamH> Well, here's a question. +[15:01:47] <prometheanfire> I suggest a 'teaching' thread on -project and see how that goes +[15:02:18] <WilliamH> Would it have been a CoC violation for someone to post a message to the poster saying something about how he should stop doing what he was doing because he was just wasting everyone's time? +[15:03:00] <WilliamH> I've thought about doing things like that a couple of times, but I'm not sure whether it is cool. +[15:03:08] <rich0> I don't think that it would be a CoC violation to point out that topics have been repeatedly raised, or that new threads are being started needlessly, or so on. That isn't suppressing discussion, just trying to channel it, and I don't think you have to be on comrel to do that. +[15:03:26] <rich0> I'd focus on channelling vs scolding. +[15:03:55] <rich0> If I replied to an agenda thread instead of starting a new one I wouldn't be offended if somebody pointed it out. +[15:04:36] <rich0> Ok, we're over an hour and I'd like to either do something or table this. +[15:05:03] <rich0> Does anybody propose any specific action at this time on behalf of council, or are we content to just start pushing for some thread discipline individually and see how that plays out? +[15:05:09] -*- K_F isn't overly concerned about the time aspect as long as the discussion is fruitful +[15:05:25] <K_F> rich0: I'd prefer a council announcement/statement to the effect myself +[15:05:35] -*- WilliamH is ok with trying to push for thread discipline for now +[15:05:37] <rich0> K_F: care to offer a proposal? +[15:05:47] <K_F> give me a min to try to write up something +[15:05:48] <blueness_> rich0: maybe we can just gently remind people to keep on topic without an official email from the council +[15:06:09] <blueness_> like jlec’s self-healing community +[15:06:29] <rich0> I'm also fine with tabling this and agreeing on a council email or whatever offline and sending it out when ready. +[15:07:05] <K_F> "The council would like the community to consider mailing list dicipline when posting to the various MLs of the Gentoo community. This includes, but is not limited to, thread dicipline and a consideration of whether a new post adds value to the discussion at hand when posting in order to ensure a good signal to noise ratio." +[15:07:35] <K_F> addendum.. +[15:07:59] <WilliamH> s/dicipline/discipline/ +[15:08:01] <Soap__> K_F: will that change anything? +[15:08:06] <K_F> "Messages should be inline quotation and cropped to the relevant quotation needed for context in order to improve readability" +[15:08:16] <ulm> also stay on topic, no html, no top posting, +[15:08:32] <ulm> and avoid messages longer than 200 words :) +[15:08:33] <rich0> :) +[15:08:43] <rich0> or at least 200 pages +[15:08:46] <K_F> ulm: not another twitter please :p +[15:09:07] <rich0> K_F: is that it? +[15:09:09] <WilliamH> ulm: lol +[15:09:22] <K_F> some posters might have 200 words of very relevant data, and in particualar references and background material if provided in proper endnotes +[15:09:41] <dilfridge> when above lenght provide a tl;dr at the top +[15:09:41] <rich0> So far we have: "The council would like the community to consider mailing list dicipline when posting to the various MLs of the Gentoo community. This includes, but is not limited to, thread dicipline and a consideration of whether a new post adds value to the discussion at hand when posting in order to ensure a good signal to noise ratio." +[15:09:48] <rich0> "Messages should be inline quotation and cropped to the relevant quotation needed for context in order to improve readability" +[15:09:49] <ulm> K_F: yeah, that wasn't entirely serious :) +[15:09:54] <WilliamH> Yeah, I don't think we can put a length limit on messages, but I know what you are getting at ulm. +[15:10:05] <rich0> Keep in mind we're not writing a glep here. +[15:11:19] <rich0> Ok, if nothing else then let's vote on his proposal: +[15:11:22] -*- rich0 yes +[15:11:26] -*- K_F aye +[15:11:32] -*- blueness_ yes +[15:11:57] -*- jlec yes +[15:11:59] -*- ulm yes +[15:12:11] -*- WilliamH abstains +[15:12:33] <rich0> dilfridge: ? +[15:12:37] <WilliamH> Sometimes there are reasons for top-posting. +[15:12:48] <dwfreed> for the guy an hour late to the meeting, my I ask what you've just voted for? +[15:13:05] <rich0> "The council would like the community to consider mailing list dicipline when posting to the various MLs of the Gentoo community. This includes, but is not limited to, thread dicipline and a consideration of whether a new post adds value to the discussion at hand when posting in order to ensure a good signal to noise ratio." +[15:13:05] <rich0> +[15:13:05] <rich0> "Messages should be inline quotation and cropped to the relevant quotation needed for context in order to improve readability" +[15:13:08] <rich0> dwfreed: ^ +[15:13:37] <WilliamH> basically a statement to post on the mls +[15:13:39] -*- rich0 notes that this is intended as a general appeal, and not some kind of no-matter-what rule +[15:13:40] <K_F> editorial changes for spelling errors allows by the person posting it to the list +[15:13:43] -*- dilfridge yes +[15:13:51] <rich0> ok, passes 6-0 +[15:13:55] <K_F> s/allows/allowed/ +[15:14:31] <rich0> Anything else on this topic? Do we want to maybe take the purpose of -project back to the list and bikeshed it there? +[15:14:50] <dwfreed> just as long as it's clear that we're not going to beat people over the head over that last sentence +[15:14:53] <K_F> rich0: should add WilliamH's dicipline -> discipline to it +[15:15:04] <rich0> K_F: will do, we don't need to vote on spelling +[15:15:10] <K_F> agreed +[15:15:43] <K_F> if there are reasons for top-posting (e.g forwarding of mail), no worries, it is an encouragement +[15:16:18] <dwfreed> top posting is the default for most mail clients (Outlook, Gmail web, etc) and people are new or lazy +[15:16:35] <rich0> Ok, then that brings us to open floor +[15:16:48] <prometheanfire> I have two things +[15:16:54] <rich0> go ahead +[15:17:23] <ulm> dwfreed: muas having a stupid default isn't an excuse +[15:17:23] <prometheanfire> First one is short, I'd suggest possibly having council report to foundation at their meeting and visa versa, just to keep everyone in sync +[15:17:35] <prometheanfire> I just thought of it, so have nothing to report this meeting :P +[15:17:46] <WilliamH> Sounds reasonable to me. +[15:17:48] <K_F> prometheanfire: the meeting logs are open to everyone +[15:17:54] <K_F> logs and summaries +[15:18:07] <prometheanfire> true, but having a proxy from each body is useful +[15:18:19] <K_F> prometheanfire: can you elaborate? +[15:18:32] <K_F> what is the goal? +[15:18:53] <prometheanfire> This is mainly for if there are any questions during the meeting +[15:19:18] <prometheanfire> a member of the body the question is proposed to is around and may be able to answer, rather then stalling the conversation at that point +[15:19:30] <K_F> prometheanfire: the meeting schedule is public, the agenda is public +[15:19:41] <K_F> prometheanfire: I'd consider it a foundation responsibility to have a member present if they consider it relevant +[15:19:58] <prometheanfire> that discounts things that are unscheduled +[15:19:58] <K_F> (as robbat2 was here for infra comments on moderation today) +[15:20:01] <rich0> So, I think both points are valid +[15:20:08] <rich0> There is value in having cross-participation +[15:20:25] <rich0> But, it might make more sense to look at the topics and have people attend to address, vs just having people always around just in case. +[15:20:54] <rich0> And of course list discussion is always better than live discussion when possible +[15:21:11] <K_F> this also goes to why I have a personal policy of not voting for issues not on agenda +[15:21:27] <K_F> it can be discussed during open floor, but no decision should be made, exactly to give pre-warning +[15:21:43] <K_F> and proper discussion ahead of time +[15:21:50] <prometheanfire> rich0: true, like I said before the meeting, I only just thought about it. but the person from the 'other' project would serve as an info source mainly +[15:22:16] <prometheanfire> not required, but encouraged +[15:22:36] -*- WilliamH could go with that -- don't require it but encourage it. +[15:22:47] <rich0> How about this, maybe both bodies should consider their agenda topics in general and reach out to the other if they think having somebody around for a specific topic would be useful? +[15:22:54] -*- K_F fails to see an issue to discuss here +[15:23:07] <prometheanfire> rich0: of course, I'd hope that's already done +[15:23:09] <rich0> But, sure, nothing wrong with more cross-participation +[15:23:24] <prometheanfire> I don't have anything more on this item +[15:23:27] <rich0> Ok, what was your other topic? +[15:23:31] <K_F> by all means, I just believe it is the responsibility of the other party as long as the agenda is public +[15:23:48] <dilfridge> so, how about sending the trustees agenda also out to the (nfp) mailing list, and making summaries of the meeting logs? +[15:23:58] <K_F> dilfridge: that'd be useful +[15:24:20] <prometheanfire> dilfridge: iirc we do have logs, though the may be behind atm +[15:24:31] <prometheanfire> dilfridge: I'll bring that up next week +[15:24:36] <dilfridge> yeah, logs sure... +[15:24:46] <robbat2> we do have logs, and a list of motions passed/rejected +[15:24:47] <K_F> summaries are the useful parts +[15:25:00] <prometheanfire> K_F: indeed +[15:25:11] <dilfridge> that thing which veremitz always reminds me that I still have to do +[15:25:16] <K_F> and agenda on mail ahead of meetings +[15:25:46] <prometheanfire> https://wiki.gentoo.org/wiki/Foundation:Meetings/2016/12 +[15:26:06] <prometheanfire> we maintain our agenda there +[15:26:13] <prometheanfire> but we should send it out anyway +[15:26:41] <K_F> " Date of Next Meeting - Jan 15 2016 19:00 UTC" ? +[15:27:01] <dwfreed> scroll down +[15:27:17] <K_F> looks better :) +[15:27:18] <dwfreed> actual meeting time is exactly 7 days from this meeting +[15:27:32] <dwfreed> I was confused at first too +[15:27:33] <robbat2> "Sunday 18th Decenber 2016 19:00 UTC on irc.freenode.net #gentoo-trustees +[15:27:34] <prometheanfire> anyway, I added that to the agenda +[15:27:39] <dwfreed> mgith want to swap those +[15:27:48] <dwfreed> and I can't type +[15:28:23] <prometheanfire> so, next? +[15:28:38] <rich0> sure, next? +[15:28:53] <prometheanfire> https://docs.google.com/document/d/10xzPUREMzZllT7dLs85JjMvlymEY9wWzYPRCnTZIsfI/edit?usp=sharing +[15:29:18] <prometheanfire> that links to a short (on purose) doc about the possibility of merging trustees and council +[15:29:32] <prometheanfire> going into reasons why and the like +[15:29:40] <prometheanfire> I mainly am asking for comments +[15:30:51] <rich0> So, I've mentioned that I'm generally in favor of an approach like this. I guess the question is what are the next steps. We're obviously not going to sort it out now. +[15:31:22] <prometheanfire> rich0: next steps are just comments from each body about the proposal +[15:31:25] <rich0> Part of me wonders if this should go into some kind of GLEP, discussed on the lists, etc. +[15:31:32] <prometheanfire> so we can get it more solidified +[15:31:45] <prometheanfire> I'm moving slowly on this on purpose +[15:31:51] <K_F> rich0: yes, that is a metastructure change, so should be a GLEP voted on by all developers +[15:31:51] <rich0> good idea, imo +[15:32:17] <K_F> it is for sure not something for open floor to solve, but should be heavily discussed on the MLs +[15:32:18] <prometheanfire> ya, it'd need to be ratified by both bodies +[15:32:35] <rich0> Are you looking for comments /now/ or just the general path forward of getting it out on the lists and discussed? +[15:32:44] <WilliamH> Wouldn't it have to be a full dev vote since it is basically a change to glep 39? +[15:32:50] <K_F> WilliamH: yes +[15:32:54] <prometheanfire> I'd like comments from councilors and trustees (will bring it up next week), then I may edit to address the comments +[15:32:56] <dilfridge> WilliamH: yes, most likely +[15:33:00] <prometheanfire> once edited I'd send it to the lists +[15:33:12] <NeddySeagoon> WilliamH: Its also a change to the Foundation +[15:33:14] <rich0> I suggest that those who are interested work on making this a more complete proposal. +[15:33:27] <rich0> Then once we have some sense of where we want to go, then we talk about the details of getting there. +[15:33:32] <WilliamH> prometheanfire: What about your bi-law that says trustees can't be on the council? +[15:33:42] <rich0> There are GLEPs, votes, election of the board, fixing the bylaws, etc. +[15:33:44] <prometheanfire> WilliamH: many changes would be needed +[15:33:50] <K_F> WilliamH: that part is actually solved if merging +[15:34:02] <prometheanfire> WilliamH: last paragraph says this isn't a complete proposal +[15:34:03] <rich0> First agree on where we're going. Getting there is a bit of a pita, but really just a lot of small details. +[15:34:05] <jlec> prometheanfire: please have this discussed on the ml. I am all for simplification, but the problem section needs some more precision +[15:34:26] <prometheanfire> rich0: exactly +[15:34:37] <K_F> once a proposal for GLEP exists, the council can have a vote on whether or not to recommend it to the wider community ahead of an all developer vote +[15:34:41] <prometheanfire> if any of you want edit rights send a request +[15:34:45] <WilliamH> prometheanfire: can you email me a .txt version? Google docs doesn't work that well for me. +[15:34:46] <K_F> ahead of that it'd be unprofessional to comment officially +[15:34:51] <dilfridge> so the main objections I've heard so far are 1) some devs dont want to be automatically part of a legal organization, 2) some people may not be able to join the board because of "real work" +[15:35:03] <prometheanfire> WilliamH: k +[15:35:11] <K_F> but can of course participate in the discussion on an individual basis +[15:35:25] <WilliamH> prometheanfire: I'll keep the link and play around with google docs to try to figure it out. +[15:35:44] <NeddySeagoon> dilfridge: Thats why Foundtion is op in, not opt out +[15:35:49] <K_F> dilfridge: I'm not sure about the US law on it, but at least here, automatical signup would be an issue for something like that +[15:36:20] <rich0> Imo, the mandatory part is simple, just keep it like it is today. Any dev can get a vote at any time if they wish, but are not required to do so ever. +[15:36:21] <dwfreed> here's a big question: as one of the few people not immediately entitled to foundation membership, and unable to vote for council at all, how would that work moving forward? assuming I get membership next week at the foundation meeting, would I be able to vote for the members of this new Board? After the formation of the Board, would other community contributors who are not developers be able to +[15:36:23] <K_F> participation in a foundation would require active acceptance +[15:36:27] <dwfreed> request membership (as Foundation does now) and thus voting power? +[15:36:43] <NeddySeagoon> K_F: here, it depends on individuals contract of emplayment +[15:37:14] <rich0> just the main difference is that if you don't ask for the right to vote, you don't vote for the board, and the current council goes away. +[15:37:25] <rich0> Essentially trustees/council get combined. +[15:37:33] <K_F> dwfreed: my $0.02 is that it would require re-alignment so that only devs are entitled to vote +[15:37:45] <prometheanfire> dwfreed: previous itterations of this proposal suggested that voting power be tied to devship (previously staff) +[15:37:48] <ulm> K_F: +1 +[15:37:53] <prometheanfire> K_F: yep +[15:37:59] <NeddySeagoon> rich0: I see it as more both go away and are replaced by a new body +[15:38:04] <rich0> And I'm all for dev-ship for things like moderators, docs, etc. +[15:38:13] <K_F> i.e either not accepting non-dev members or two voting classes to foundation +[15:38:14] <rich0> NeddySeagoon: sure +[15:38:14] <prometheanfire> rich0: ditto +[15:38:27] <K_F> the latter being a bylaw change +[15:38:28] <dilfridge> K_F++ +[15:38:36] <rich0> ok, we're getting into the weeds a bit +[15:38:54] <rich0> IMO there really is no issue with making it happen. First we need to explain how it would all work and make sure we WANT it to happen. +[15:39:12] <NeddySeagoon> rich0: yes +[15:39:15] <K_F> well, from personal situation, I likely couldn't participate in a board +[15:39:16] <prometheanfire> so, now that I brought that up, I requests specific comments on the suggested goal (what we want to do) +[15:39:18] <rich0> Once people agree on what to do, actually doing it is rarely the issue. +[15:39:28] <prometheanfire> not how to get there, as rich0 said, that gets into the weeds +[15:39:29] <K_F> as that is restricted in my employment contract.. +[15:39:31] <rich0> ok, so, let's start getting this out there +[15:40:01] <K_F> (strictly speaking, it requires pre-approval) +[15:40:03] <rich0> K_F: I think that is a very legitimate concern, and probably worth a little thread. Would we give up too much with having a single board, or is there another solution? +[15:40:06] <prometheanfire> I'll do the same at next weeks trustees meeting +[15:40:17] <rich0> Ok, anything else on this? +[15:40:28] <NeddySeagoon> K_F: I had to get my employers permission in 2008 +[15:40:34] <dwfreed> K_F: with Foundation's current bylaws, there is one class of membership; the only distinction is in admission requirements for that class (which really it isn't a distinction, just devship is considered automatically qualifying for the significant contributions to gentoo requirement) +[15:40:45] <K_F> dwfreed: yes, that would likely change +[15:41:21] <prometheanfire> after next week I update the proposal and send it out for general comments/concerns, using that data I'll make a specific proposal, once we have a specific proposal the next step would be plan of action then implimentation +[15:41:48] <prometheanfire> so, I'm done :P +[15:41:54] <rich0> Ok, any other topics? +[15:42:20] <dilfridge> yes +[15:42:25] <rich0> I'll just mention that I might work on a comrel GLEP, and if anybody is interested they're welcome to pile on. +[15:42:25] <prometheanfire> two hours of meeting :P +[15:42:28] <rich0> No details now. +[15:42:34] <dilfridge> not so much for us but for prometheanfire and the next trustee thingy, +[15:42:44] <prometheanfire> rich0: possibly +[15:42:49] <K_F> rich0: yeah, I need to finish up something on security GLEP as well +[15:42:50] <dilfridge> please also discuss whether going the SPI way would be useful +[15:42:50] <prometheanfire> rich0: ping me with more info +[15:42:56] <NeddySeagoon> rich0: yes please +[15:42:56] <rich0> ok +[15:43:15] <prometheanfire> dwfreed: sure +[15:43:22] <prometheanfire> dilfridge: sure +[15:43:29] <prometheanfire> dwfreed: misping, again +[15:43:36] <dwfreed> I figured :) +[15:43:42] <rich0> SPI is probably worth another look now that debian/arch have gone that way, and maybe some of our previous concerns are addressed. That might also fit into the combined board changes/etc. +[15:43:58] <K_F> rich0: indeed +[15:44:21] <rich0> That it, dilfridge? +[15:44:21] <NeddySeagoon> rich0: indeed +[15:44:24] <dilfridge> yep +[15:44:32] <rich0> Ok, any other other topics? +[15:44:54] <prometheanfire> dilfridge: added to the adgenda +[15:44:58] <dilfridge> thanks +[15:45:13] -*- rich0 bangs the gavel +[15:45:21] <K_F> rich0: thanks for chairing +[15:45:22] <rich0> Ok, thanks all. I'll post the log and write up the summary. +[15:45:29] <jlec> thanks guys +[15:45:32] <K_F> rich0: as a matter of procedure, will you post the mail to -project? +[15:45:51] <rich0> K_F: oh for the etiqutette thing? Sure +[15:46:05] <K_F> yes, good +[15:46:07] <rich0> I'll post to -dev-announce diff --git a/meeting-logs/20161211.txt.asc b/meeting-logs/20161211.txt.asc new file mode 100644 index 0000000..bb9dda7 --- /dev/null +++ b/meeting-logs/20161211.txt.asc @@ -0,0 +1,16 @@ +-----BEGIN PGP SIGNATURE----- + +iQIcBAABCAAGBQJYTb8VAAoJEPnrMGeMBPQU7SYP/0YVbqU5u+BtrsPMviVuGD8d +C38s0JfGjKOjNN+EZjRpFxJO89XfpjTk6SYw960Xp6DIrTBBZrtdGyWUGQgBpKsU +zgt4gguuGxH+XaPUUyv7Wj1iA3/gyYW4fd3xzakhOKOAKKpuA55c+0pGbCRVwLam +AJDnEY/QbaM8kr8mWzkzLKjNmwGiHl31YhSdEstsIOcQUBNUBcAj7thlxgYwLYXs +MyKPonzh7g64W7kyQ5Iqu1JXKBHWShnY0z2D+6WTtDpgfxKPFH8oW7AVE3pqg5SO +WjxgObz3RsEjS59tCUrn6f+Ygn8Iucn080FguJ9MT7X2l5ojnnlAmocHbSSQgx3K +sUOyw/Nw8MgvmiRG1/+ouj658BPjoOx0FVWFx1Q/lQOfUmcgV2CtFd7Kb5xYPA6Y +gXCKROsnFHqBhzrhy1QTLl1h4vB3rmxhw6bUSRx+ez5unEXNsTFTfAscTXvnWQ29 +UZ8mOJ00HgYdBFgdC/rDusixah/0IwI+XorpBeNO3pUHV41CfhIoLiZOZTeWWbhM +xyAKBFqkc4Eeztde3aGKnKVEEiAaHivUlgimLaxEsetg3VSij3gmwLK/zS8fVLP6 +xzO8cVjBD44nNRsnGoQrsIlLUk/qjVMnmQ5c09+Hddc+sHSYdJIYzwBtli4zPwxo +nZoom/GzCKezbGrG8zB8 +=v5W6 +-----END PGP SIGNATURE----- |