20:01:26 <ttx> #startmeeting tc
20:01:27 <thingee> o/ <-- back from vacation
20:01:27 <edleafe> hey dtroyer_zz - wake up!
20:01:27 <openstack> Meeting started Tue Sep 13 20:01:26 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:30 <openstack> The meeting name has been set to 'tc'
20:01:33 <annegentle> welcome back thingee
20:01:36 <mtreinish> o/
20:01:37 <ttx> Our agenda for today:
20:01:43 * dtroyer_zz kicks bouncer again
20:01:43 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:50 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:02:01 <ttx> #topic Add Sukhdev as extra-atc for ironic
20:02:07 <ttx> #link https://review.openstack.org/366890
20:02:16 * jroll lurks
20:02:20 <ttx> As mentioned in the commit message, it's past the deadline for elections or summit discounts
20:02:28 <ttx> But that should not prevent us from approving that one
20:02:38 <jroll> yep, this is for the future
20:02:47 <ttx> Looks like overwhelming support, will approve now unless someone objects
20:03:27 <ttx> ok approved
20:03:34 <ttx> #topic Tags for devstack and tempest plugins
20:03:34 <annegentle> thanks jroll for explaining to Sukhdev
20:03:44 <jroll> annegentle: no problem :)
20:03:47 <ttx> mtreinish proposed the addition of two new tags in the same vein as type:horizon-plugin
20:03:53 <ttx> * Add tag for devstack plugins (https://review.openstack.org/366301)
20:03:56 <ttx> * Add tag for tempest plugins (https://review.openstack.org/366302)
20:04:02 <ttx> mtreinish: anything to add ?
20:04:22 <mtreinish> ttx: well the only open thing about those is what to do about in repo plugins
20:04:28 * ttx refreshes his vote
20:04:37 <mtreinish> by themselves the tags are pretty straightforward now
20:04:54 <ttx> mtreinish: it's a similar question for horizon-plugins
20:04:59 <mtreinish> but the majority of plugins are included in project repos (it's an antipattern for tempest plugins, but expected for devstack)
20:04:59 <annegentle> nice thing is the repos are named consistently
20:05:32 * devananda lurks
20:05:46 <johnthetubaguy> so we could add that type tag into the main project repo, or is that a bit odd?
20:05:53 <dhellmann> mtreinish : are there docs explaining why it's an anti-pattern?
20:06:02 <ttx> johnthetubaguy: so far we haven't (for horizon-plugins)
20:06:05 <mtreinish> dhellmann: there are (and they're linked in the tempest tag commit msg)
20:06:16 <ttx> since for the releases website we have those in separate paragraphs
20:06:24 <dhellmann> mtreinish : ah, ok, I hadn't looked at that patch since I voted
20:06:42 <johnthetubaguy> ttx: ah, right.
20:06:51 <dtroyer_zz> is there expected to be only one type_ tag per repo/deliverable?
20:06:53 <mtreinish> johnthetubaguy: I was thinking about adding a subtype on the tag like contains:tempest-plugin or something like that
20:06:58 <dhellmann> dtroyer_zz : yes
20:07:11 <ttx> We have majority on those two, and nobody objected during the week, so I think we can approve those now
20:07:40 <dhellmann> dtroyer_zz : although if we end up moving the values we use for rendering releases.o.o into the releases repo, we could allow multiples in governance
20:08:01 <dtroyer_zz> that might solve a couple of things then
20:08:19 <dhellmann> yeah, types and release models change more often than anticipated
20:08:29 * dtroyer_zz was thinking about the client-library stuff we kicked about a few weeks ago
20:08:30 <ttx> and deliverables contents
20:08:33 <johnthetubaguy> mtreinish: seems simpler using the same tag for both though, but that makes we think about tag precedence order
20:09:40 <ttx> I propose we approve those and use them for pure plugins repo until we have a larger solution
20:09:46 <dhellmann> ttx: ++
20:09:47 <dtroyer_zz> ++
20:09:49 <ttx> (like for horizon-plugins)
20:09:49 <mtreinish> johnthetubaguy: it is, I was just thinking out loud
20:09:58 <johnthetubaguy> ttx: ++
20:09:58 <mtreinish> ttx: ++, that's why I proposed it that way :)
20:10:05 <ttx> ok, approving now
20:10:28 <ttx> #topic Barcelona Design Summit cross-project workshops
20:10:36 <dims> mtreinish : thanks, sounds good to me
20:10:41 <ttx> OK, so we need to start organizing the cross-project content we'll have in Barcelona
20:10:52 <ttx> In terms of resources, we can use up to 6 time slots and up to 4 parallel rooms
20:11:00 <ttx> (we can, of course, use less)
20:11:24 <ttx> Given that Ocata is a short cycle, I'd rather focus on a few key topics (giving some of them a double-slot) rather than the usual scattergun
20:11:30 <mordred> ++
20:11:35 <ttx> Who is interested in setting that up ?
20:11:49 <johnthetubaguy> I personally find 3 parallel rooms frustrating, so maybe 4 would be pushing it
20:11:58 <johnthetubaguy> I could help with that
20:12:13 <dhellmann> I would offer, but I'm up for election this term.
20:12:20 <ttx> johnthetubaguy: we can mix and match. Have a few slots with only 1 or 2 in parallel and others with 3 or 4
20:12:28 <anteaya> dhellmann: why does that matter?
20:12:32 <ttx> depeding on the topic
20:12:44 <anteaya> dhellmann: tc and non tc folk have worked on this in the past
20:12:47 <johnthetubaguy> ttx: good point, that works
20:12:59 <dhellmann> anteaya : I thought it has been mostly tc members
20:13:03 * dtroyer_zz raises hand again incase my disconnect didn't pass it through
20:13:05 <annegentle> 2 parallel is about my limit johnthetubaguy :)
20:13:12 <anteaya> dhellmann: it has been, but it doesn't have to be
20:13:15 <ttx> How would you prefer to do the topic selection ?
20:13:24 <ttx> Can't remember what we used last time
20:13:28 <annegentle> dtroyer_zz I didn't see ya do it so might not have gotten thru
20:13:33 <anteaya> dhellmann: I don't see how your status would interfere with your ability to participate if that is what you want
20:13:35 <dhellmann> ttx: the etherpad worked well for collecting ideas
20:13:36 <ttx> (but then I delegated it last time)
20:13:45 <johnthetubaguy> did we do etherpad, then narrow them down?
20:13:53 <annegentle> johnthetubaguy yeah I think so
20:14:02 <anteaya> dhellmann: I would offer to help but I won't be in barcelona
20:14:10 <johnthetubaguy> yeah, the google forms we tried sucks because not all computers in the world can use a google form
20:14:22 <ttx> so let's create an etherpad, set expectations that we'll likely only select a few topics
20:14:31 <dims> was this what we used last time? https://etherpad.openstack.org/p/newton-cross-project-sessions
20:14:36 <ttx> set some deadline
20:14:58 <ttx> and start cracking ?
20:15:10 <dims> ttx : i can help with this
20:15:15 <dtroyer_zz> dims:  that looks familiar
20:15:18 <johnthetubaguy> so the newly elected TC should probably vote on that, so is that the deadline? or do we need it before then?
20:15:28 <ttx> #link https://etherpad.openstack.org/p/ocata-cross-project-sessions
20:16:00 <ttx> johnthetubaguy: we usually don't vote. We only select a few members to run it. We could select members that are not for reelection like dhellmann suggested
20:16:31 <johnthetubaguy> I didn't mean formally as such, just infromally
20:17:05 <johnthetubaguy> ttx: when do you need the details uploading into the schedule?
20:17:28 <johnthetubaguy> two weeks before that seems a good deadline for suggestions
20:17:45 * ttx adds a bit of data
20:20:42 <ttx> OK, we have the basic data in
20:21:01 <ttx> any volunteer for a -dev thread announcing the etherpad ?
20:21:07 <ttx> What deadline should we set ?
20:21:11 <johnthetubaguy> I can send a note out in the morning
20:21:13 <johnthetubaguy> if we pick a date
20:21:14 <annegentle> ttx so six slots, am I reading it right?
20:21:28 <annegentle> thanks johnthetubaguy I can help with the etherpad wrangling
20:21:35 <ttx> #action johnthetubaguy to announce the CPW planning etherpad
20:21:46 <dtroyer_zz> Oct 1-ish?  thats a few days to still get to two weeks befor for the schedule
20:21:47 <ttx> annegentle: yes, see above
20:22:15 <annegentle> ttx got it, thanks
20:22:36 <johnthetubaguy> dtroyer_zz: that sounds about right
20:22:46 <ttx> dtroyer_zz: yes, something like end of week Sunday Oct 2
20:23:06 <johnthetubaguy> yeah, just thinking about giving us time mon/tuesday to look through before this meeting
20:23:07 <ttx> Oct 1 sounds good
20:23:53 <johnthetubaguy> #info oct 1 deadline for adding suggestions to https://etherpad.openstack.org/p/ocata-cross-project-sessions
20:24:17 <dhellmann> ttx: did I correctly identify the slots that could serve as doubles?
20:24:28 <ttx> dhellmann: yes
20:24:34 <dhellmann> one was obvious, the other had more of a gap
20:24:35 <dhellmann> k
20:24:47 <ttx> please #info yourself if you volunteer to help
20:24:58 <ttx> #info ttx volunteers to help
20:25:04 <dhellmann> and of course we could have 2 part sessions spread over the 2 days if we want, too
20:25:15 <ttx> #info johnthetubaguy volunteered to help too
20:25:31 <annegentle> #info annegentle volunteers too
20:25:35 <dtroyer_zz> #info dtroyer volunteers
20:25:50 <mtreinish> ttx: I can help if there aren't enough people already :)
20:26:03 <ttx> usually all the TC members end up participating in the vote selection anyway
20:26:04 <anteaya> mtreinish: info yourself
20:26:10 <dims> #info dims volunteers to help
20:26:22 <ttx> it's more who is availabel to take more of a lead position
20:26:28 <ttx> or available
20:26:37 <mtreinish> ttx: ah, ok voting is enough for me then
20:26:38 <ttx> OK, anything else we need to settle now ?
20:26:51 <johnthetubaguy> that sounds like a good starting point to me
20:27:11 <annegentle> johnthetubaguy ttx Oct 7th eob a good deadline then? Or did you mean Oct 2nd?
20:27:22 <ttx> Oct 1 is good
20:27:26 <johnthetubaguy> I thought we said Oct 1st
20:27:28 <annegentle> end of day I mean
20:27:29 <annegentle> ok
20:27:34 <annegentle> that's easier, updting etherpad
20:27:37 <ttx> One thing I would really like to see discussed is some common understanding around plugins for proprietary technologies
20:27:47 <ttx> annegentle: I see it on te etherpad already
20:27:55 <ttx> (although we'll probably have to prepare that one up front so that it doesn't turn into a shoutfest)
20:29:16 <ttx> OK, let's move on to next topic
20:29:34 <ttx> #topic Finalizing Ocata goals
20:29:41 <ttx> dhellmann: want to introduce this one ?
20:29:50 <ttx> or should I
20:30:30 <dhellmann> given that we're so close to the summit, and we haven't nailed down this goal definition, I have withdrawn it for now
20:30:46 <ttx> #link https://review.openstack.org/349069
20:31:03 <dhellmann> I will propose a session for the summit, and haypo has agreed to lead it, to discuss what needs to be done and figure out what our next steps are
20:31:16 <dhellmann> and then over the course of ocata we can discuss the goal definition more
20:31:28 <dhellmann> with the intent to resubmit it for pike
20:31:48 <ttx> That will come soon enough
20:32:14 <ttx> dhellmann: is there anything to do to formally close the list for Ocata ?
20:32:21 <mtreinish> dhellmann: so we'll only have the one goal for ocata?
20:32:34 <dhellmann> mtreinish : unless someone else proposes another
20:32:49 <dhellmann> ttx: we've approved the one goal, so I think that's it
20:33:03 <mtreinish> dhellmann: I can write up one for the tempest plugin split out (like we talked about in nyc) this week
20:33:09 <dhellmann> I'll propose a session to discuss that, too, in case folks have implementation questions that they would like shared
20:33:32 <dhellmann> mtreinish : we should get that on the list, but given the time frame I don't know if it's realistic to get that approved either :-/
20:33:46 <mtreinish> dhellmann: yeah, that's fine. But it'll be a starting point if nothing else
20:34:00 <ttx> feels like we could use a (small) backlog of goals
20:34:06 <dhellmann> mtreinish : sure
20:34:10 <ttx> since we were a bit short this time
20:34:18 <annegentle> ttx that's a good idea
20:34:24 <johnthetubaguy> so thinking about to the goals for pike, do we start the discussion on those at the PTG? or at this summit?
20:34:29 <dhellmann> ttx: we have https://etherpad.openstack.org/p/ocata-tc-goals but we were missing someone to do the writing work
20:34:46 <mtreinish> johnthetubaguy: both?
20:34:47 <dhellmann> johnthetubaguy : we need to be collecting info at the summit
20:34:55 <ttx> johnthetubaguy: start the discussion at the summit, but refine goal selection in the month(s) before PTG
20:35:04 <dhellmann> right, what ttx said
20:35:44 <johnthetubaguy> right, thats what I was thinking, I am just wondering what we are doing to help make that happen, I am wondering if we have a slot to discuss that at the end of the week, probably not I guess
20:36:06 <ttx> ok, let's move on. Skipping next topic since flaper87 is not around and would rather be when we discuss it
20:36:15 <dhellmann> ttx: are we going to hold "forum" sessions in barcelona?
20:36:30 <ttx> johnthetubaguy: I think the idea is to think about things that could make good goals, not really to discuss any particular one in detail
20:36:53 <ttx> dhellmann: not really, although some of the fishbowl sessions will look a lot like what Forum sessions will be
20:36:54 <dhellmann> it might be useful to have a cross-project session to discuss them in general
20:37:17 <annegentle> dhellmann I like that idea
20:37:18 <johnthetubaguy> dhellmann: yeah, I am thinking that, if only to get folks thinking about them
20:37:19 <ttx> depends on the topic really
20:37:20 <dhellmann> maybe someone else could volunteer to lead that
20:37:30 <dtroyer_zz> dhellmann: yes, as they are new and generated a lot of questions already
20:37:31 * dhellmann doesn't want this to be "Doug's goals for OpenStack"
20:37:33 <johnthetubaguy> I don't mind leading something along those lines
20:37:52 <ttx> let's rotate the burn
20:37:58 <dhellmann> johnthetubaguy : great, thanks
20:38:10 <ttx> ok, moving on
20:38:15 <ttx> #topic Open discussion
20:38:23 <ttx> I have several things to discuss
20:38:24 <annegentle> dhellmann nice, yeah
20:38:33 <ttx> I'll do a new version of the "principles", probably tomorrow. Hopefully it will be more consensual
20:38:56 <ttx> although I need to check back with original drafters if they will still be comfortable co-authoring it :)
20:39:09 <ttx> the fringe of people who think we should not define principles at all will probably still be disappointed
20:39:17 <mordred> shrug
20:39:22 <ttx> Another thread that went ballistic last week is the alignment of the future election periods w/ the cycle
20:39:37 <ttx> The language in the charter is a bit non-deterministic, mentions both "design summit" and "summit", so we need to update it (after this election round) for the PTG/summit new world order
20:39:38 <dims> y fireworks
20:39:56 <ttx> 3 options have been proposed: elections just before summit, elections just before summit but with PTL overlap and delayed "takeover", or elections before PTG
20:40:08 <ttx> I'd argue that there is no perfect time to run elections, we are always busy.
20:40:22 <ttx> But then the current timeframe (R-4 to R+0) arguably falls when we are the busiest
20:40:36 <ttx> well no, R-7/R-5 would actually be worse
20:40:45 <ttx> What's your take on that ?
20:41:00 <ttx> (not that we'd make a decision now, more of a temperature read on the room
20:41:21 <dtroyer_zz> There is a definite perception in parts of the community that PTLs are per-cycle already, even if that is not strictly true
20:41:32 <johnthetubaguy> I am not sure there is a good time, with all the extra staggering we have coming up
20:41:48 <mtreinish> ttx: tbh, I'm fine keeping it relative to the summit like now, even if it's in the middle of the cycle in the post-ptg world
20:41:51 <dtroyer_zz> adjusting the election to better prepare for actually making that true seems like a less-disruptive adjustment
20:41:54 <dhellmann> I underestimated how many teams see their PTL as their release driver, so I think I'm OK with shifting elections to align with the PTG. When we do that, we could build in more lead time than we have now.
20:42:04 <mtreinish> it just adds more buffer incase the torch is passed on
20:42:11 <dhellmann> although I would also be ok with the proposal as it stands
20:42:16 <sdague> I think more lead time would be good just to make transitions smoother
20:42:40 <ttx> Personally I dislike the whole idea of asking the current PTl for room requirements at the Design Summit while elections are started. Makes for weird discussions
20:42:43 <johnthetubaguy> yeah, more lead time would certainly help smooth the bumps
20:42:44 <dhellmann> sdague : yeah, I just think 4 months is too long
20:42:49 <sdague> dhellmann: sure
20:42:59 <edleafe> are there many cases of non-smooth transitions?
20:43:08 <ttx> edleafe: there were enough of them
20:43:08 <dtroyer_zz> under the old way, would 2 more weeks have been enough? 1 month?
20:43:11 <sdague> honestly, this could also be a time where we've grown so much diversity in projects that there is no one size fits all here
20:43:20 <annegentle> sdague that's my sense of it too
20:43:21 <dhellmann> edleafe : we've had several PTLs disappear right at the end of the cycle when we needed them to coordinate release work, yes
20:43:32 <sdague> because the base iaas things definitely work as PTL is release driver
20:43:34 <edleafe> dhellmann: ttx: ok thanks
20:43:53 <sdague> but tons of horizontal things don't even have releases per say
20:44:06 <dhellmann> sdague : I do not think this is an area where we want teams to "innovate"
20:44:42 <fungi> as a ptl for a project with no real ties to the cycle, it seems like we shouldn't be pinning ptls to some release cycle anyway, but while deliverables following the release cycle are a minority, projects with at least one of those deliverables are likely a majority
20:44:59 <johnthetubaguy> well, in base iaas decisions are very often heavily aligned with in person meet up cycles, more than the release as such
20:45:18 <ttx> I also would like to make sure we use the summit in the now-middle of the cycle to bootstrap the thinking about the next cycle, and not knowing who will drive that next cycle by then is kind of a problem
20:45:27 <sdague> dhellmann: maybe, but it's also going to be odd to just apply spherical human rules to all projects an assume uniformity
20:46:13 <dhellmann> sdague : the only reason this is even coming up as an option now is the ptg change; no one has objected to a single schedule for elections before afaik
20:46:22 <ttx> There is no urgency since we won't be able to change the charter until after this election round anyway, but if you could think about it and the various options we have, that would be great
20:46:40 <johnthetubaguy> ttx: I see most projects working more like a team than that, but I guess thats different in different projects
20:47:06 <anteaya> johnthetubaguy: yes, different in different projects
20:47:59 <ttx> johnthetubaguy: I still think it's easier if the person in charge of the current cycle is not necessarily the person in chargfe of the next, and you know who is in charge of the next early enough to prepare the cycle properly
20:48:24 <flaper87> o/
20:48:45 <fungi> however, with the described cycle "overlap" this seems better suited to delegates anyway
20:49:17 <david-lyle> assuming delegates exist
20:49:49 <fungi> it seems like in situations where projects realize they have a need for that, they grow delegates to take it on?
20:50:18 <johnthetubaguy> ttx: maybe, not sure I am totally visualising your suggestions properly yet, will apply thinking cap
20:50:19 <persia> For this purpose, it is probably best to assume there is *someone* in charge of a release, even if that role ends up switching mid-development cycle or remains the PTL, or whatever.
20:50:23 <david-lyle> when it works, ulitimately it all cascades back to the PTL
20:50:45 <sdague> fungi: that does assume there is a bench willing to do that. And that that coordination cost doesn't outweigh the benefits of the extra hands there.
20:51:10 <annegentle> my instinct says there's less of a bench than we think --- because there are many more small projects than large
20:51:25 <dtroyer_zz> I do think having a common model for the cases where the PTL delegates this stuff is the important bit.  for small enough projects it is all PTL
20:51:29 <fungi> and at any point in time, there are probably two releases in progress (one in the early stages of planning, one being finalized) and so you'll have a ptl changing in the middle of one of them regardless
20:52:00 <sdague> annegentle: and in even large projects, the amount you need to put into your head to do that role effectively, means it's unlikely to end up with 2 to 3 folks being able to commit to that in overlapping windows
20:52:22 <annegentle> sdague true that
20:52:23 <johnthetubaguy> sdague: I think that articulates my concern well
20:52:25 <annegentle> sdague bigger brains
20:52:42 <sdague> that's at least largely how things have faired in the Nova space, the PTL is the one that needs to sort all the parts and keep that straight
20:52:56 <sdague> which frees up other core team members to focus on landing those parts
20:53:03 <ttx> sdague: I'd argue that the person in charge of the release has an easier job if they don't need to care about the next, though
20:53:07 <ttx> And currently they do
20:53:07 <pleia2> 1/g 114
20:53:07 <sdague> as they don't also need the whole picture
20:53:29 <sdague> ttx: that assumes everything gets done in a cycle, and things are 3 or 4 cycle efforts
20:53:44 <sdague> which, all the hard stuff usually is
20:53:55 <ttx> I mean, *I* send those PTls emails about room requirements, I can tell you they would prefer not to have to think about it
20:54:31 <fungi> was there more of a driver for this proposal besides the release team being concerned that there was a lack of continuity for release liaisons over the course of a release, or poor hand-off between liaisons?
20:54:52 <sdague> anyway, just thinking aloud here to make sure all the info is on the table if a decision does get made
20:54:56 <ttx> fungi: which proposal are you talking about ?
20:55:26 <ttx> We have words in the charter that won't mean anything post-Barcelona, so we need to decide what to do :)
20:55:28 <fungi> well, the change in ptl election scheduling/efficacy and release stewards proposals tend to dovetail into each other, so both i guess
20:56:10 <ttx> the release stewards stuff was just a way to make the "let's keep them scheduled against SUmmit" option easier
20:56:16 <fungi> release steward delegation seems like at least a partial answer to retaining the current election schedule
20:56:34 <ttx> ensure a bit of extra continuity
20:56:52 <fungi> recognizing that there's probably no perfect time in the schedule for ptl changing of the guard anyway
20:56:55 <ttx> but you get the same with waiting 3 months to take over as sdague suggested
20:57:34 <ttx> the only issue with that one is that you get a +9months commitment from PTls instead of a +6months
20:57:55 <mordred> to be fair - most ptls serve more than one term anyway - well, except for me
20:58:11 <fungi> you served many terms as infra ptl ;)
20:58:18 <mtreinish> mordred: or any of the heat ptls
20:58:19 <annegentle> I sense we should try to get bigger benches... as a primary goal, avoiding burnout and disappearing PTLs and release tasks falling under an imaginary bus.
20:58:26 <david-lyle> I think you're optimizing for <10% of the projects in the big tent
20:58:39 <ttx> mordred: right, which is why release stewards can help them organize. But then some trusted member that would keep an eye on N+1 would do the trick too
20:58:45 <annegentle> so which proposal would optimize for more backup and redundancy?
20:58:50 <david-lyle> the waiting bench of people wanting to take on the drudgery is not so deep
20:58:57 <ttx> david-lyle: what would be your preference for the election timeframe ?
20:59:02 <annegentle> david-lyle that's what I'm wondering, the percentage
20:59:03 <dims> ttx : guess also it did not come across as "this is what we saw work in many teams, so this is optional best practice"-kind-of-message
20:59:20 <johnthetubaguy> so if we have a world were PTLs are elected about a month before the PTG, what do we loose, the N+1 driver at the summit?
20:59:22 <david-lyle> honestly the current timing makes sense to me
20:59:29 <sdague> dims: maybe some of the case studies on which teams it was working on would be helpful
20:59:30 <david-lyle> there is very little overlap
20:59:31 <ttx> david-lyle: define current
20:59:36 <annegentle> david-lyle I sense cross-project PTLs have that difficulty more
20:59:48 <dims> sdague : right
20:59:50 <ttx> david-lyle: because currently it's defined against sumit timing and summit is moving
20:59:58 <dtroyer_zz> david-lyle: current reletive to the release cycle or to the summit?
21:00:02 <ttx> so there is no status quo
21:00:18 * dougwig notes the time.
21:00:24 <david-lyle> ttx, right, with the release
21:00:31 <david-lyle> but not trying to split the streams
21:00:35 <fungi> i don't so much have an opinion on when is a good time for ptl elections, as much as i see forcing a delay in ptl role changing hands across all projects as suboptimal
21:00:36 <johnthetubaguy> or current to the PTG?
21:00:40 <ttx> ok, time to close it
21:00:50 <ttx> #endmeeting