20:04:46 #startmeeting tc 20:04:47 Meeting started Tue Sep 2 20:04:46 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:04:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:04:49 Our agenda for today: 20:04:51 The meeting name has been set to 'tc' 20:04:55 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:05:00 #topic Final selection of our User Committee nominee 20:05:06 This is in replacement of Ryan Lane. 20:05:13 I got your suggestions and reached to them. The following people confirmed: 20:05:20 Andrew Mitry, Beth Cohen, Chet Burgess, Jacob Walcik, Jonathan Proulx 20:05:27 I set up a Condorcet poll so that we designate someone during this meeting 20:05:30 Sending links now. 20:05:50 do we have advocates who want to speak for these candidates? I don't actually know any of them. 20:05:58 OK sent. Please vote before the end of the meeting ! 20:06:12 Yes, any quick support ? 20:06:38 yeh, these folks are largely unknown to me as well, might be nice to get some statements from folks about them to help with the decision, otherwise I feel it will basically be random 20:06:41 these are all great candidates, I'm happy to talk through support 20:06:47 yeah, I'm a bit stuck too 20:06:56 and it's great we have more than before :) 20:07:00 Chet is a nova dev, he's the only one I know 20:07:11 Jon Proulx did some doc work 20:07:24 Beth worked on the Architecture Design Guide and has been operating OpenStack clouds since pre-grizzly. 20:07:31 Andrew Mitry is the Comcast architect 20:07:42 is the candidate meant to be a user, or just represent technical folks on the user council? 20:07:53 Jacob Walcik helped me write the diablo install guide, ha ha. He is a Rackspace private cloud engineer who supports a ton of private clouds 20:08:00 Chet's stackalytics: http://stackalytics.com/?release=all&user_id=cfb-n 20:08:36 so we have affiliateion for those besides Jacob and Andrew? Curious what the rest's roles are wherever they happen to work 20:08:37 sdague: ++ i don't feel i have enough information to make a recommendation 20:08:56 sdague: that was to your previous point about getting statements from these folks 20:08:57 Jonathan Proulx was an author on the Ops Guide and runs an OpenStack cloud at MIT and is very active on the operators mailing list. He tests upgrade instructions and most recently wrote a network troubleshooting section. 20:09:02 Chet works for metacloud IIRC 20:09:23 Andrew is Comcast, Jon Proulx is MIT 20:09:30 Beth works for verizon now, has worked for Cloud Technology Partners 20:09:40 annegent_: cool, thanks 20:09:58 and to quantify "a ton" I think three digits? 20:10:19 really they're all great candidates and I'd love to find ways to get them all involved regardless of an "appointment" 20:10:47 OK, we can close the vote tomorrow if you'd like time to research them more 20:10:52 indeed, it hardly feels right to choose if we have volunteers willing to serve (how often does *that* problem come up?) 20:11:18 they are a limited crew dut to the NDA on the user survey though 20:11:20 * russellb just joined, sorry for being late 20:11:21 so we have to pick 20:11:22 (plane, etc.) 20:11:25 right dhellmann my thoughts exactly 20:11:42 yeah, the NDA thing makes this weird 20:11:45 ttx: wow, ok, I didn't realize that was the constraint 20:11:52 i love that we have an nda 20:11:56 also means that ideally you don't want to be changing the people very often 20:12:51 ok, how about we let that vote open until tomorrow night 20:12:57 sounds good 20:12:57 that works 20:13:09 that gives you time to do reasearch. You can also vote all equal 20:13:17 and defer to those with an opinion 20:13:32 #topic Graduation review: Zaqar (ex-Marconi) (part 1) 20:13:40 flaper87: o/ 20:13:41 At every end of cycle we look at currently-incubated projects, discuss progress 20:13:42 did those who nominated these people have statements with them? 20:13:44 o/ 20:13:52 and see if any are ready to be made a part of the next OpenStack integrated release development cycle 20:13:58 jeblair: no, we nominated them :) 20:14:05 We did Barbican two weeks ago. Today (and possibly next week) we'll do Zaqar 20:14:08 ttx: i mean, did "we" include statements as to why? :) 20:14:13 Then we'll do Ironic next week (and possibly the next) when Deva is back from vacation 20:14:21 jeblair: anne nominated like almost all of them :) 20:14:31 jeblair: I saw names, but nothing very formal 20:14:39 NB: kgriffs has recently moved to another position, so he designated flaper87 as his permanent delegate until the September election 20:14:49 Let me summarize the last Marconi graduation episode... 20:14:59 At the graduation review last cycle, I think the concerns fell into three broad categories 20:15:09 1. Pecan vs. Falcon, and more generally lack of alignment with the rest of OpenStack 20:15:14 #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030385.html 20:15:17 okay, so next time, we should ask for a narrative along with the nominating statement, because i have no basis for making the decision and have no avenues for any real research before tomorrow 20:15:25 2. Data-plane vs. Control-plane approach 20:15:29 jeblair: +1 20:15:38 3. Questionable backends (MongoDB/AGPL issue, SQLA db-as-a-queue antipattern) 20:15:47 both exposed in that thread: 20:15:55 #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030367.html 20:16:01 Then the graduation request was withdrawn: 20:16:09 #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030638.html 20:16:17 fast-forward to today 20:16:23 flaper87: what would be your assessment of the current state of Zaqar in incubation? 20:17:09 flaper87: and thanks for joining to represent the project 20:17:19 So, we've addressed the missing pieaces we had since last graduation evaluation. 2 points remain to be discussed. The point w.r.t pecan vs falcon and the one with data-plane vs control-plne 20:17:25 russellb: my pleasure :) 20:17:47 the data-plane vs control-plane thing is incredibly unfortunate, IMO, as it has been completely clear to me what zaqar was trying to be from the beginning 20:17:50 As for #3, we've added (thanks to one very helpful GSoC mentee) a redis driver 20:17:56 as in, SQS like data API 20:18:06 russellb: +1 20:18:14 russellb: i'm not sure i follow what you're saying 20:18:22 i'm saying it's unfortunate that the debate came up 20:18:29 russellb: thanks, that clarifies 20:18:30 it doesn't make sense to me 20:18:34 What we've done for that matetr is to communicate and share as much as possible the project's goals 20:18:34 cool 20:18:44 #link https://wiki.openstack.org/wiki/Zaqar/Frequently_asked_questions#Is_Zaqar_a_provisioning_service_or_a_data_API.3F 20:19:02 * markmc likes that summary of the data-orientated position of the team 20:19:15 the API requirements, particularly 20:19:52 i guess we should go over each of the concerns ttx mentioned 20:19:54 russellb: i think, if i'm understanding it correctly, the relevance here though is not that it is implementing SQS, but rather that it is doing it from scratch rather than re-using existing queuing technologies 20:19:56 and we've sort of already started on #2 20:20:10 (whew, i'm still on topic :) 20:20:14 jeblair: :) 20:20:25 jeblair: perhaps, though that wasn't the context of the debate as i understood it 20:20:34 that wasn't the context 20:20:36 more that folks fundamentally disagreed with an SQS like API in the first place 20:20:44 jeblair, I don't think I've ever seen a plausible description of how you'd implement a multi-tenant SQS-like REST API using existing queuing technologies 20:20:46 the context was why the project is not providing, say, rabbitmq as a service 20:21:04 right, i think i've seen some pretty good analysis on that from zaqar, and they felt it didn't make sense 20:21:05 jeblair, e.g. using RabbitMQ as a backing for something like that seems bizarre to me 20:21:08 so where I remain conflicted is whether SQS is essential infrastructure to OpenStack, vs. being a useful part of the ecosystem. 20:21:18 doesn't mean the backends they have are the best approach, of course 20:21:49 fwiw heat will be using zaqar as an option regardless of integrated status, since it solves a real problem for us 20:21:50 okay, so i guess there's two levels of potential objection -- that it does not use (eg) rabbit internally to back its api, and that it does not simply provision/expose (eg) rabbit 20:22:01 it sounds like the data/control plane debate mostly focused on the second 20:22:08 yeah, exactly 20:22:46 the first debate is really more about #3 in ttx's list 20:22:55 err 20:22:56 there is also the issue that if it really is just the second it shouldn’t be a service 20:22:57 flaper87: are any openstack integrated projects besides heat looking at zaqar to fill some need? 20:23:01 jeblair: its certainly my recollection that people were upset / confused that rabbit was being reimplemented in mysql 20:23:05 i mean, should it use rabbitmq, or something else other than what it has today 20:23:08 sdague: Trove and Swift 20:23:10 mikal: but it's not rabbit at all 20:23:13 and horizon 20:23:15 it's very different 20:23:15 sdague: ^ 20:23:22 flaper87: interesting, what's the swift use case? 20:23:26 russellb: sure, but that's what people were saying last cycle 20:23:34 i know, and i think that's silly :) 20:23:37 flaper87: or are those up there anywhere 20:23:58 sdague: I still have to write swift's ones down because they came up in a quick chat with notmyname 20:24:07 flaper87: ok 20:24:57 mikal: yeah people are hearing queues and thinking amqp 20:25:09 flaper87: it wasn't so much a swift use case as a heat use case? 20:25:13 flaper87: iirc? 20:25:43 annegent_: there are 4 projects that I've talked to and they've shared ideas and needs for zaqar: Horizon, Heat, Trove and swift 20:26:15 I've started putting those use cases here: https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases 20:26:21 flaper87: great 20:26:33 since mose of them happened on informal chats and talks at the ATL summit and during Juno 20:26:36 * mikal looks 20:26:39 s/mose/most/ 20:27:02 Trove's use case is to communicate with guest-agents 20:27:15 The data-plane vs. control-plane discussion is somethign Zaqar has little leverage about -- if we decide we don't want to add data-plane stuff anymore, there is littlethey can do on their side 20:27:23 What about the other 2 concerns ? 20:27:39 flaper87: how does ironic talk to its guest agent? Is that a use case as well? 20:27:53 I think the addiiton of Redis solves #3 20:28:08 mikal: I don't know how they do it but I think it might make sense for Ironic too 20:28:10 we are no longer implementing a queue on top of SQL or AGPL 20:28:22 Murano is using MQ based agent too 20:28:22 It's a bit toung though 20:28:23 ttx: yup 20:28:33 flaper87: is it landed yet ? the redis support? 20:28:34 sahara too no ? 20:28:39 ttx: yup, yday 20:28:43 ok 20:28:43 probably other projects as well just to budge in :p 20:28:44 (phew) 20:29:00 which driver runs in the gate now? 20:29:07 dhellmann: mongo 20:29:10 what about #1, alignment with the rest of openstack? 20:29:24 sdague: thanks 20:29:24 dhellmann: any comments on oslo integration? 20:29:40 We've been adopting oslo libraries as they're released 20:29:47 i suspect it's tied to dataplane/controlpane discussion too, i.e. falcon justification is mostly that it's more dataplane-oriented than pecan 20:29:54 and keeping the files coming from the incubator updated 20:30:13 it looks like they have several of the low level libraries in their requirements file. 20:30:19 flaper87: are you the liaison, or is someone else doing that? 20:30:21 i don't think i've seen a whole lot of falcon discussion since the last round 20:30:23 * mikal needs to drop off now for a flight, laters 20:30:24 dhellmann: I am 20:30:26 was there that i've forgotten? 20:30:27 mikal: not to derail, but ironic doesn't have a guest agent 20:30:37 russellb: it hasn't come up again 20:30:39 russellb: there hasn't been 20:30:58 ok, so a concern ... but i'd really hate for *that* to be the only blocker 20:31:06 i probably wouldn't block if that was the only thing personally 20:31:20 that's still fixable, if the project commits to re-starting work there 20:31:41 TBH, we focused on making v1.1 consistent and cleaning it up 20:31:57 I think a better time to discuss a migration to Pecan would be v2 when it comes 20:32:27 russellb: yes, seems like our gap-analysis-style workflow would work for any sort of pecan<>flask work 20:32:50 flaper87, I saw that v2 is when you're planning on removing the lookup-message-by-ID thing? 20:32:59 flaper87, when do you think that work will happen? 20:33:02 flaper87: anything worty of note in https://wiki.openstack.org/wiki/Zaqar/Incubation/Graduation ? 20:33:17 so from a deployment perspective if zaqar is in, that means operators have to deploy and maintain a nosql infrastructure 20:33:27 sdague: required? 20:33:31 it's all optional now right? 20:33:40 markmc: We're planning to start discussing it at the Kilo summit and we'll probably decide there if it makes sense to give the community a chance to digest v1.1 before start working on v2 or if we should probably just go for it 20:33:42 russellb: there is no real sqla backend 20:33:44 as in, only if you want zaqar for your tenants 20:33:53 and we're talking about heat and other services requiring it 20:33:54 right, because we determined that was an anti-pattern, right? 20:34:08 i think other services using it should be optional, that's a scope jump 20:34:11 should discuss that more 20:34:18 because originally this was a "tenant only" service in my view 20:34:27 not infrastructure 20:34:30 my sense is this project has a tenant only scope 20:34:33 ttx: we've put lots of efforts on integrating with the whole OpenStack ecosystem and also on having a complete documentation for users and developers 20:34:36 the heat use case is to communicate with tenants, though, right? 20:34:43 annegent_: stevebaker just said heat was going to use it 20:34:54 whether or not zaqar is integrated 20:35:16 stevebaker: could use some more detail on that i think 20:35:20 out of meeting perhaps 20:35:37 It would be our prefered method for heat/server interaction, with a fallback to swift TempURLs if not available 20:35:40 the faq says it's very much over-cloud, so we're getting mixed messages here 20:35:41 heat is gonna use what? sorry for not cathcing that 20:35:42 putting zaqar in definitely has some implications for what infrastructure is expected to be maintained 20:36:22 sdague: heat also was going to rely solely on keystone v3 when it wasn't widely deployed :) 20:36:50 stevebaker: ah there's the tie-in I was trying to recall, you have a method and a fallback 20:37:04 we still support v2. This is different though, since the template author chooses what transport method they will use 20:37:19 stevebaker: ok, that's a good point 20:37:32 there is no magic, an explicit choice is always made 20:38:39 it's really unfortunate that we're in a state where projects are only considered successful if they are granted integrated status, because to me zaqar feels like a solid part of the ecosystem, but I'm not sure I believe SQS is essential infrastructure. 20:38:47 ok, so if it's an optional tenant initiated thing, that seems reasonable to me 20:38:55 So at this point I hear "operational infratsructure extra burden (due to NoSQL deploy)" and "should we really reinvent a queue system rather than piggyback on one" 20:39:07 anything else ? 20:39:16 ttx: and "API stability" i think, since they're already planning v2 things 20:39:26 russellb: +1 20:39:29 russellb: ++ 20:40:00 do we have information from deployers beyond rax? Is this seeing adoption in the community already? 20:40:01 FYI I'd like scalable, durable, ha queues for internal swift (ie to more efficiently implement swift features 20:40:21 russellb: not really planing v2, we want to give the community and ourselves enough time to use the existing API, which we consider stable 20:40:37 notmyname: it's probably worth exploring that in more detail ... as it sounds like it's in conflict with what other projects use for "infrastructure" queues 20:40:43 I'm fine with keeping them in incubation over Api stability and freshness of Redis driver... but i don't want to keep them incubating if we don't believe deploying NoSQL is acceptable, or if we prefer control-plabe to data-plane. Because there is little short of rewriting all that they can fix that 20:40:55 as in, if what you're talking about isn't optional tenant initiated features, then i think it's out of the scope i had in mind 20:40:56 notmyname: do you see zaraq providing that better than an amqp bus? 20:41:02 sdague: catalyst will (is?) use zaqar too 20:41:08 ttx: yeah that makes sense 20:41:11 ttx, agree 20:41:19 My sense is that it's super useful for cloud tenants and would be great for our cloud providers to have it at the ready. And other integrated projects want this ability. They did a great job of writing docs too for multiple audiences. 20:41:44 so in all cases we need to make up our minds on those (is deploying NoSQL acceptable, is inventing our own queue acceptable, is data-plane acceptable) 20:41:55 FWIW, I think v1.1 is a stable API. It has things that some folks don't like but I wouldn't consider it unstable because of that 20:42:07 becasue if we answer no, there is no need to keep them on the wire 20:42:10 so from a docs perspective I won't cry "too heavy integration burden" - this team has done well. 20:42:13 flaper87: maybe a detailed response to each identified concerns before next week would assist 20:42:22 russellb: +1 20:42:26 ttx, agree - they're the key questions; and sound more like incubation questions ... not that we can't revisit, though 20:43:14 markmc: I agree it would be unfortunate to reject on those architectural grounds, but if we don't believe that is accepatble, i prefer we reject late than we accept 20:43:15 markmc: agreed 20:43:15 definitely need to resolve them, it's no fair to keep them on the wire 20:43:15 if no projects *require* zaqar, than why would deploying nosql be acceptable? 20:43:37 jroll: did you mean not acceptable? 20:43:52 ttx, they're not so much architectural concerns as scope concerns, but yeah 20:43:54 russellb: yes, sorry 20:43:56 I know mordred has a strong opinion on the dataplane vs. controlplane thing 20:44:09 he should be coming back really soon now 20:44:09 jroll: i tend to agree with that, fwiw, though the increased burden should still not be taken lightly 20:44:23 I have a strong opinion that we should piggyback on domain specialists where we can 20:44:30 i.e. not reinvent queues 20:44:37 i believe we can expect mordred and devanand1 back for next weeks meeting 20:44:41 unless we really really can't work with the existing ones 20:44:42 but can we in this case? more than they've done with redis? 20:44:45 russellb: I'm always skeptical about deploying more services :) 20:44:52 rabbit isn't the answer, imo 20:44:56 far from it 20:45:18 re backing zaqar with rabbit: http://blog.flaper87.com/post/marconi-amqp-see-you-later/ 20:45:22 zaqar isn't reinventing queues. as in, it's offering things that don't currently existing with stuff like amqp. one example is that zaqar's queues are durable. 20:45:26 agree, I think we've chased that rabbit down the wrong hole 20:45:26 IMO it's a different service, we shouldn't compare with Rabbit or AMQP 20:45:33 markmc: ++ 20:45:46 vkmc: ++ 20:45:47 we are covering the cases that Amazon SQS/SNS cover 20:46:14 notmyname, vkmc: good point 20:46:42 kinda like magneto db, would you call it that they are offering something that a layer ontop of cassandra has vs trying to cover features of say a google compute service or aws ? 20:46:44 right, that's my thinking as well 20:47:14 flaper87: I think that's enough for this meeting, we'll continue next week. Anything we can discuss on the mailing-list between now and then will help clarify 20:47:30 flaper87: you got the list of "concerns" ? 20:47:32 thanks flaper87 for taking up the ptl role 20:47:49 ttx: It'd be nice if we can summarize it now before you change topic 20:47:55 annegent_: my pleasure! 20:47:57 ok, let me try 20:48:01 ttx: just to make sure we're on the same page 20:48:31 #info concern on operational burden of requiring NoSQL deploy expertise to the mix of openstack operational skills 20:48:58 #info concern on should we really reinvent a queue system rather than piggyback on one 20:49:10 (that one can be debunked by explaining the SQS case, durable queues, etc) 20:49:37 #info concern on dataplane vs. controlplane, should we add more dataplane things in the integrated release 20:49:49 #info concern on API v2 being already planned 20:50:14 that's an odd summary of the conversation, fwiw 20:50:18 #info concern on the maturity of the NoQSL not AGPL backend (Redis) 20:50:20 makes it sound like all concern, no support 20:50:34 markmc: it's not a summary of conversation, it's a summary of concerns :) 20:50:39 markmc: i'm trying to list the concerns for flaper87 to consume 20:50:57 I'll put those concerns in an etherpad and answer them before next week 20:50:58 I honestly think they've addressed many of these 20:51:07 markmc: +1 20:51:09 markmc: i'm not saying they didn't 20:51:09 * flaper87 hides 20:51:11 :D 20:51:12 and we're not doing a very good job of explaining why they're still a concern 20:51:22 it's like, "here guys, have another go on the merry-go-round" 20:51:43 I'm just trying to summarize what points are the potential pain points 20:51:47 sure 20:52:14 flaper87: does that work ? May I switch topic ? 20:52:29 ttx: go ahead, I got the list and I'll work on those before next week 20:52:35 thanks everyone! 20:52:36 flaper87: thanks! 20:52:39 flaper87: you might want to push a governance change to support your graduation, too 20:52:51 flaper87: contact me if you have doubts on how to do that 20:52:52 #topic Other governance changes 20:52:53 ttx: it will be my pleasure :) 20:52:57 * Propose guidelines for adopting new official projects (https://review.openstack.org/116727) 20:53:03 Discussion is still on-going on this one. 20:53:11 I wonder if we can really adopt those before we discuss the future of Programs though 20:53:21 like whether the current program team really takes responsibility over the adopted project or not 20:53:34 * Add reference to neutronincubator project (https://review.openstack.org/117000) 20:53:41 On this one there is clear disagreement from Infra on the approach chosen in Neutron 20:53:46 jeblair started a thread at: 20:53:49 #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/044125.html 20:53:57 Not really sure it went anywhere though, and we need to make progress fast here 20:54:15 jeblair: how is that discussion going ? 20:54:21 ttx: so we're tweaking the incubator proposal 20:54:46 markmcclain: to something that would work better for infra? 20:54:53 items targeted for spinout will go into separate repo and items targeted to merge back into the main tree will look at feature branch 20:55:07 ok 20:55:09 usually a patch to governance to add a repo doesn't happen until after the repo exists 20:55:14 that should align and address jeblair's concerns 20:55:20 jeblair: remove your -1 when you're convinced 20:55:22 markmcclain, ttx: i think those two directions are good 20:55:42 * Add a Mission Statement for Orchestration (Heat) (https://review.openstack.org/116703) 20:55:44 anteaya: wanted to discuss concept w/TC before adding workload to infra :) 20:55:44 I'm trying to run through the guidelines for say, the training project 20:55:51 This one is still ongoing 20:56:03 * Add oslo.log to the Oslo program (https://review.openstack.org/116994) 20:56:11 This one is a no-brainer, will approve post-meeting unless someone objects 20:56:16 * Add oslo.concurrency to the Oslo program (https://review.openstack.org/117345) 20:56:18 markmcclain: kk, for the benefit of anyone wondering where the repo is 20:56:20 Same for this one 20:56:25 * The Oslo program is adopting pylockfile (https://review.openstack.org/117622) 20:56:34 There is some discussion over this one, like *why* we are doing this 20:56:59 so i'll let it cook until next week 20:57:08 #topic Open discussion 20:57:20 jogo: want to mention your thread ? 20:57:44 Anything else, anyone? 20:57:49 ttx: sure 20:58:11 thread: http://lists.openstack.org/pipermail/openstack-tc/2014-September/000777.html 20:58:35 I think jogo's idea was a pretty interesting one. I think if people came up with top 5 items that would be pretty interesting, and provide some feedback into what the cross project sessions should be 20:58:45 jogo: ++ 20:59:11 sdague: yeah, right now I am more interested to see what the different lists are then figuring out what do do with the results 20:59:16 as I am not sure what to expect 20:59:23 we've talked about the desirability of this, and jogo's suggestion gives us some concrete structure for how to get started 20:59:37 should we hold that discussion on the -dev list, or the tc list? 20:59:40 ok, post them on the -dev list 20:59:41 i think it's a useful exercise 20:59:54 i think it's also worth making sure we all agree on what problem we're trying to solve with the exercise 21:00:02 jogo, maybe you can start a thread on the -dev list then for us to reply to? 21:00:03 dhellman_: I wanted us to agree that it was a good idea first, but yes, the posts themselves should be on -dev 21:00:19 increased focus is definitely good, though i think the bigger pain (that leads to people thinking about focus) is just our review bottleneck problems 21:00:22 jogo: sounds like the go-ahead you've been waiting for 21:00:23 ttx: makes sense 21:00:25 overall project throughput 21:00:45 ttx dhellmann: great I will start a -dev ML thread for folks to respond to 21:00:50 and also talk about what the expected consumption of this list would be in the end 21:00:53 russellb: perhaps we should be thinking about ways to train more reviewers, then 21:00:55 I will focus the thread on TC memebers but leave it open for anyone to respond to 21:01:07 as in, is it just a sync exercise? or is it intended to go into saying "no" more? or? 21:01:22 also I think it will be good as a focusing excerise for the driver writers to recognize what *is* important to the community as a whole 21:01:27 russellb: I would like for us to pick 1-2 items from the list and put together a "task force" or whatever to actually work on them 21:01:34 * russellb nods 21:01:37 yeah that's all good stuff 21:01:41 they might be surprised that it isn't *their* plugin 21:01:46 to provide ptls/core teams some coverage in setting individual project priorities 21:01:48 russellb: the example I gave in another thread was sdague's log standardization, and notification standardization would be another 21:01:48 russellb: I was envisioning this as just an exercise to see where we stand 21:01:53 review bottleneck and scope widening are hand-in-hand from my view 21:01:56 honestly, right now, I'm mostly interested in figuring out how my view of the world with what I think is critical aligns with other people in the community 21:01:59 ok, time is up 21:02:09 sdague: ++ thats the idea 21:02:09 cool, yeah, that sounds useful 21:02:12 Thanks everyone 21:02:14 thanks everyone! 21:02:15 #endmeeting