14:01:52 <dhellmann> #startmeeting releaseteam
14:01:53 <openstack> Meeting started Fri Sep  9 14:01:52 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:57 <openstack> The meeting name has been set to 'releaseteam'
14:02:01 <dhellmann> courtesy ping: ttx, dims, tonyb
14:02:47 <ttx> o/
14:03:11 <dhellmann> our agenda for today is in the r-4 week on https://etherpad.openstack.org/p/newton-relmgt-tracking
14:03:33 <dims> o/
14:03:41 <dhellmann> #topic pending release requestes
14:03:44 <dhellmann> #undo
14:03:45 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f23bd8c6e10>
14:03:45 <dhellmann> #topic pending release requests
14:03:49 <dims> almost there !
14:04:14 <dhellmann> the oslo.db release is done, and I assume the constraints update is being reviewed
14:04:26 <dhellmann> #link https://review.openstack.org/368001
14:04:31 <dhellmann> it hasn't passed the check jobs yet
14:04:58 <dhellmann> the openstackclient 3.3.0 release is on the wrong branch, so I -1ed that until we can decide if it's an ocata release or they need to backport things
14:05:17 <dims> right
14:05:31 <dhellmann> there are some stable releases, which I was deferring paying attention to until early next week
14:05:44 <dhellmann> ttx, you mention a test failure on the liberty ansible release
14:06:24 <ttx> yes, asking for reordering
14:06:27 <dhellmann> hmm, that's weird
14:06:30 <ttx> indeed
14:06:31 <dhellmann> ok, I'll look at that problem today
14:06:36 <ttx> looks like an edge failure of the test
14:06:50 <ttx> because the patch seems properly formatted
14:07:05 <dhellmann> probably
14:07:39 <dhellmann> how about the patch changing announce location for neutron stadium projects - https://review.openstack.org/#/c/367986/ ?
14:07:57 <ttx> looking
14:07:59 <dhellmann> I wasn't sure if we wanted independent projects sending on the -announce mailing list
14:08:28 <ttx> bah, at this stage, it's noisy enough that it won't make much difference
14:08:35 <dhellmann> ok
14:08:46 <dhellmann> approved, then
14:08:47 <ttx> Also those probably should not really be independent
14:08:48 <dims> ihrachys : do we have a way to stop "networking-* stadium deliverables already announce on -announce@ mailing list."? guess not
14:08:53 <ttx> but that's another story
14:09:22 <dhellmann> yes, I was talking with ihrachys about the tagging of those projects earlier today
14:09:26 <ihrachys> dims: I dunno. why?
14:09:42 <ttx> The question is. who's the target audience of those, and I would argue it's the OpenStack consumers, not the OpenSTack producers
14:09:45 <ihrachys> ttx: agreed they should be following neutron release model
14:09:50 <dhellmann> I suspect that as more of them are spun out of the stadium, they'll stop being part of the tent project list anyway
14:09:55 <dims> ihrachys : we are talking about "	I wasn't sure if we wanted independent projects sending on the -announce mailing list "
14:09:59 <ttx> so -announce rather than -dev
14:10:03 <ihrachys> ttx: I advocated for it in Austin, but armax had a different opinion
14:10:14 <ttx> that happens
14:10:26 <ihrachys> dims: ack. if you think it's wrong, we can instead change all of them to -dev
14:10:34 <ihrachys> dims: as long as there is some consistency, I am fine
14:10:34 <dhellmann> ihrachys : no, -announce is good
14:10:50 <ihrachys> dhellmann: I also think so, because if neutron is there, then plugins to it should go the same way
14:10:54 <dims> y, works for me
14:11:11 <dhellmann> ihrachys : maybe you and armax and I can have a hallway conversation about the models in barcelona
14:11:26 <dhellmann> some cycle-based model seems to fit better
14:11:32 <ihrachys> dhellmann: + for that
14:11:47 <dhellmann> though we should see how the dissolution of the stadium plays out, it might save us the effort of changing the models
14:12:10 <ttx> yes, I can't wait for another heated thread
14:12:20 <dhellmann> are there any other pending reviews we should prioritize?
14:12:33 <ihrachys> dhellmann: some of them actually seem to struggle with delivering releases that are compatible with neutron-server releases, and I believe part of the problem is they don't know how to manage it properly. if they are funnelled thru the branching process automatically, they would have less things to screw
14:12:39 <dims> ttx : haha
14:12:50 <ihrachys> ttx: :D
14:12:53 <ttx> feels like we covered most of the actionable backlog
14:12:55 <dhellmann> ihrachys : I agree
14:13:10 <dhellmann> #topic ocata schedule
14:13:16 <dhellmann> #link https://review.openstack.org/#/c/357214/
14:13:26 <ttx> I think it's time to make it official
14:13:28 <dhellmann> are we ready to approve the schedule?
14:13:30 <dhellmann> yep, ok
14:13:35 <dhellmann> shall we all pile on +2s?
14:13:35 <ttx> the sad is that we lost the pile of +1s
14:13:36 <dims> +2
14:14:07 <dhellmann> ttx: yeah
14:14:33 <ttx> In retrospect you should have done the typo fix in a subsequent patchset. Would pimp our team activity stats too
14:14:39 <dhellmann> heh
14:14:50 <dims> :)
14:15:00 <dhellmann> yeah, I'll handle that differently next time
14:15:13 <dhellmann> and I'll send email announcing it as approved later today
14:15:31 <ttx> Fun fact, we have nearly twice as many patchsets than a well-known vocal vertical team
14:16:00 <dims> automation for the win! :)
14:16:35 <dhellmann> it's a good thing we have more work to do, or we wouldn't qualify to vote in the ptl election soon ;-)
14:16:48 <dims> LOL
14:17:01 <dhellmann> ok, moving on
14:17:07 <dhellmann> #topic Governance reviews
14:17:13 <dhellmann> #link https://review.openstack.org/#/c/364307/
14:17:41 <ttx> I singled two
14:17:46 <dhellmann> that one looks like it's an empty puppet repo
14:17:59 <dhellmann> I assumed they were adding more stuff to their current release
14:18:15 <dims> y, don't understand the rush
14:18:20 <dhellmann> I guess we've done that for other deployment projects, since they're so decomposed already. I don't know why I voted -1 here
14:18:35 <dhellmann> although the governance patch shouldn't block creating the repository
14:18:36 <ttx> For that one I'm "whatever, dude"
14:19:05 <ttx> if EmilienM wants it, he shall have it
14:19:17 * EmilienM reads
14:19:48 <dhellmann> maybe I thought it would interfere with the validation for the final newton deliverable?
14:19:54 <dims> EmilienM : you can do anything you want with that repo right now, so what's stopping its use?
14:19:58 <dhellmann> I don't remember now if we kept the check to ensure that all repos were being tagged
14:20:07 <ttx> dhellmann: that part will likely skip Newton anyway
14:20:15 <dhellmann> meh,  it's a separate deliverable so that wouldn't matter
14:20:24 <EmilienM> dims: nothing, they can start working on it
14:20:24 <dhellmann> ttx: right, but all of the scripts don't know that
14:20:36 <EmilienM> dims: someone from Mirantis afik wanted to start coding on it
14:20:42 <ttx> dhellmann: there are other bits that won't get released in Newton
14:20:47 <dhellmann> yeah
14:20:56 <dims> Lol, will ping them internally as well
14:21:06 <dhellmann> I can't remember why I said -1 on this one. Maybe I needed more caffeine.
14:21:08 <ttx> we almost need branches on the yaml file
14:21:11 <dhellmann> dims, I'm going to go ahead and +1 this
14:21:12 <EmilienM> dhellmann: no worries :D
14:21:31 <dhellmann> ttx: yes, or to move some of the information into the releases repo instead of the governance repo
14:21:32 <ttx> starting to wonder if we should not maintain the repo/mapping/releasemodel ina separate file in releases
14:21:45 <dhellmann> ttx: exactly
14:21:54 <dims> dhellmann : ok
14:21:56 <dhellmann> we can talk about that at the summit
14:22:00 <ttx> the only part that touches governance there is the election roll
14:22:15 <ttx> but they could ask us for that data
14:22:44 <dhellmann> ttx: I would be ok with tags and repos being defined in governance, and deliverables being defined in releases
14:22:51 <ttx> although the release:none stuff would not make a lot of sense there meh
14:22:58 <anteaya> anyone can create an electoral roll now
14:22:58 <dhellmann> although even some of the tags might be easier to manage in releases
14:23:04 <ttx> ah, yes, that's an option
14:23:18 <dhellmann> types and models
14:23:18 <anteaya> fungi: has a script and gerrit permissions now allow anyone to run it
14:23:33 <ttx> anteaya: but they use the team/repo mapping that is in projects.yaml
14:23:39 <anteaya> yes
14:23:51 <ttx> if we move that away in the releases repo, that means election rolls are controlled by release team
14:23:57 <fungi> oh, right, i missed it's meeting time
14:24:00 <ttx> I kind of like that, but I suspect others might object
14:24:17 <dhellmann> fungi : sorry, I was rude and left you out of the courtesy ping
14:24:21 <ttx> so we probably need to keep the project/repo map in governance
14:24:37 <fungi> dhellmann: no worries. i caught up on other things!
14:24:37 * anteaya waits for fungi to catch up on the electoral roll creation bit
14:24:50 <dhellmann> ttx: yeah, I think we can move part of the data without breaking how we manage the election roles
14:25:08 <ttx> anyway, not an urgent discussion at all
14:25:18 <dhellmann> no
14:25:22 <dhellmann> we have another governance change
14:25:23 <dhellmann> #link https://review.openstack.org/#/c/364355/
14:25:36 <dhellmann> that's to change the models for some of the tripleo projects
14:25:54 <dhellmann> and to add some type tags
14:25:55 <ttx> for newton or ocata ?
14:26:06 <fungi> i don't have a vested interest in where project metadata ends up, just let me know and i can adjust tools/owners.py in the system-config repo (also we can move that elsewhere)
14:26:07 <dhellmann> for ocata, I think
14:26:24 <ttx> the quickstart change applies to newton in a way since it won't be released in newton
14:26:36 <ttx> image-elements...
14:26:47 <dhellmann> fungi : I'm not comfortable with the release team owning something related to building election rolls, but there are some parts that would be easier to manage if we did them in the releases repo instead of governance
14:27:09 <fungi> the tags presumably?
14:27:11 <ttx> ...follows milestones currently
14:27:12 <dhellmann> oh, image-elements is doing beta tagging
14:27:21 <dhellmann> fungi : yes, and deliverable composition
14:27:33 <ttx> the type:library things... were those branched for newton ?
14:27:35 <dhellmann> ttx: yeah, so this would be an OK change for us to take now, I guess
14:28:03 <fungi> all electoral roll generation needs to know is the names of official teams and a list of their deliverable repos and their extra-atcs
14:28:05 <dhellmann> ttx: no, they used b3 tags
14:28:19 <dhellmann> ttx: inccorrectly, but I didn't notice because the type was "unknown"
14:28:19 <ttx> so those don't really apply for newton
14:28:33 <dhellmann> ttx: well, those are only declaring the type properly
14:28:40 <ttx> type:library stuff means branch
14:28:46 <dhellmann> fungi : yep, that would stay in governance
14:29:12 <dhellmann> ttx: hmm, yeah
14:29:37 <dhellmann> ok, so let's wait until ocata opens for this one
14:29:37 <ttx> I guess if we are done with all lib branching we can change that now
14:30:00 <dhellmann> heh
14:30:35 <dhellmann> we're tracking what has been branched and what hasn't in the dashboard, so I think it's safe to make this change now. I also think it's fine to wait 2 weeks.
14:30:44 <ttx> OR we tag 5.0.0 and branch VERY soon
14:30:57 <ttx> (on os-cloud-config)
14:31:24 <ttx> (same for os-collect-config)
14:31:48 <ttx> and the other two
14:31:55 <dhellmann> EmilienM : do you know the plan for a final release for the tripleo os-*-config projects? are they going through rc1, or a final version # next week?
14:32:15 <ttx> If they do final release I would leave the type out and turn them to milestone-driven
14:32:22 <ttx> for the time being
14:32:51 <dhellmann> ttx: the way the build works now, no matter when we add the type tag it's going to cause the newton page to be rendered differently
14:33:00 <dhellmann> that's another argument for putting that info in the releases repository
14:33:05 <fungi> was "lib branching" the reason for needing a stable branch of openstackclient?
14:33:24 <dhellmann> fungi : yeah, that's why it ended up with one
14:33:29 <dhellmann> that project may need a different type tag
14:33:37 <fungi> dtroyer wasn't sure exactly why he was asked to add stable branch management to a non-library client utility
14:33:38 <EmilienM> dhellmann: i'll do rc1 next week
14:33:54 <EmilienM> dhellmann: and if we have bugfix between rc1 and final, we'll do rc2 or/and final release
14:33:58 <EmilienM> is it ok?
14:34:18 <ttx> EmilienM: yes, but we'll probably align the governance change you proposed to reflect that
14:34:35 <dhellmann> fungi , dtroyer : the project follows a cycle-based model, so it'll get branches. it has the type:library tag now, which is probably just bad metadata, but only led to the branch happening early (it's not why it branched, just why that happened last week)
14:34:35 <ttx> i.e. remove type:library and set release:cycle-with-milestones instead
14:34:41 <EmilienM> damn, you talked about os-
14:34:47 <ttx> os- yes
14:34:50 <EmilienM> I need coffee too... sorry
14:34:57 <EmilienM> so no, final version next week
14:35:01 <ttx> Coffee at 4pm ? No, you need beer
14:35:08 <dhellmann> EmilienM : ok
14:35:12 <EmilienM> ttx: it's 10h34am here
14:35:20 <ttx> EmilienM: no excuse
14:35:21 <EmilienM> ttx: I live in Canada :)
14:35:28 <dhellmann> EmilienM : rye, then?
14:35:36 <ttx> EmilienM: I know, that's why you need alcohol
14:35:39 <EmilienM> dhellmann: :)
14:35:44 <fungi> dhellmann: so we expect to have stable point releases of openstackclient? who consumes those?
14:35:57 <EmilienM> #action EmilienM to propose tripleo os-* final release next week
14:35:58 <dhellmann> fungi : distros who want bug fixes
14:36:04 <fungi> got it
14:36:22 <fungi> and should the repo have stable:follows-policy then?
14:36:39 <ttx> dhellmann: so I think the change is ok, except the os-* changes should  remove type:library and set release:cycle-with-milestones instead
14:36:39 <dhellmann> oh, it's classified as a library because it shows up in the dependency list for a bunch of projects
14:36:41 <fungi> tonyb wasn't sure where sable branch management extended in this case
14:36:43 <dhellmann> including other client libs
14:36:50 <fungi> fun
14:36:56 <dhellmann> http://paste.openstack.org/show/570213
14:37:10 <fungi> so it's being treated as a sort of "command-line library" i guess
14:37:15 <dhellmann> yes
14:37:22 <dhellmann> that will change when those projects rely on osc-lib instead, I guess
14:37:26 <ttx> fungi: could be proprietary then
14:37:27 <ttx> :P
14:37:32 <fungi> indeed!
14:37:35 * stevemar lurks
14:37:46 <fungi> good thing it's released under an osi-approved license
14:37:51 <ttx> stevemar: unfair, we didn't even use the trigger word
14:37:57 <fungi> so i don't have to complain
14:38:00 <dhellmann> ttx, EmilienM : so where did we land? does this patch need to be changed or do we just wait?
14:38:03 <dtroyer> dhellmann:  (coming to this late) that is likely to not change for the projects that treat OSc CLI as their API interface
14:38:08 <dims> ttx : you said osc :)
14:38:18 <stevemar> ttx: you used a word that starts in o and ends in penstackclient
14:38:20 <dims> or dhellmann did !
14:38:28 <ttx> dhellmann: 16:36 <ttx> dhellmann: so I think the change is ok, except the os-* changes should  remove type:library and set release:cycle-with-milestones instead
14:38:35 <dhellmann> dtroyer : ah, ok, I thought that osc-lib was to avoid that, but maybe type:library is ok then
14:38:46 <dtroyer> it is, for python interfaces
14:38:53 <dtroyer> puppet calls the cli
14:39:00 <dhellmann> ttx: could you post that on the review?
14:39:07 <ttx> Sure, if you agree
14:39:12 <dhellmann> dtroyer : yeah, we don't count it as a lib for things like puppet
14:39:14 <dhellmann> ttx: yes
14:39:25 <EmilienM> dtroyer: right, we trust and rely 100% on osc
14:39:30 <dhellmann> dtroyer : more for things like python-*client
14:39:33 <EmilienM> dtroyer: so we don't have to rewrite a client in puppet
14:39:48 <EmilienM> dtroyer: we did it in the past and failed to maintain it.
14:40:23 <dhellmann> I think that's resolved, so let's move on
14:40:28 <dhellmann> #topic open discussion
14:40:31 * stevemar unlurks
14:40:38 <dhellmann> ttx, you wanted to discuss the release stewards thread?
14:41:02 <ttx> quickly
14:41:21 <ttx> people seem to read something else than what I wrote, which is... interesting
14:41:42 <dhellmann> I wonder if it would have been less controversial if we hadn't attached a new name
14:42:01 <ttx> Some seem to think it's yet another mandate from "the top", so I think we need to take clearer ownership of it soon
14:42:34 <dims> ttx : "we" as in release team?
14:42:35 <ttx> that said, we would not be the only consumers of that person
14:42:38 <ttx> dims: yes
14:42:47 <ttx> which is why the name evolved
14:43:07 <ttx> and that may explain some of the confusion
14:43:44 <dhellmann> I think a lot of the friction is actually coming from teams that have their PTLs as release managers more than team leads
14:43:48 <ttx> We are saying that the person who will do release liaison for the cycle would also be the point of contact to organize the related PTG, attend the N-1 summit...
14:43:54 <dhellmann> or at least where that's the focus of the leadership work
14:44:26 <ttx> i.e. we define a new "role" that goes beyond pure release liaisoning
14:44:47 <ttx> which implies it's the same person doing all the components of that role
14:45:11 <dhellmann> I wonder if we need to make this change right away?
14:45:16 <ttx> (compared to defining a set of tasks which would be held by default by PTL and which he could (or not delegate to one or more people)
14:45:45 <ttx> I think we don't need to rush anything
14:45:48 <dims> ttx : ihrachys point needs to be addressed - "There is a significant difference between release liaison role defined to handle cross project work, and release steward defined for what seems to be purely internal project matters."
14:45:54 <fungi> i read it as no actual governance model change, just encouraging teams to have per-release liaisons (stewards) as ptl delegates
14:46:04 <dims> from http://markmail.org/message/cbyowascvsuwrqvu
14:46:09 <dhellmann> if the teams who are opposed to this don't see the issue because they're focused on finishing this release, and we can wait until they do see the issue, it might be easier to address at that point
14:46:19 <ttx> dims: I think he is mistaken, the role would not be purely internal
14:46:22 <dhellmann> fungi : yes, that's pretty much it
14:46:30 <ttx> In particular that person would get to talk to ProductWG / Ops
14:46:44 <ttx> attend "forum" sessions in Boston
14:46:47 <dhellmann> s/get/be expected to/
14:46:54 <ttx> caolesce the feedback and build priorities
14:46:59 <dims> ok both external and internal
14:47:22 <dhellmann> yes, it's taking the liaison role and adding new responsibilities that used to be part of the PTLs duties
14:47:35 <dhellmann> because the PTL election cycle and release cycle no longer sync up
14:47:38 <fungi> i'm not a fan of the subsequent proposals to officially alter all ptl elections or efficacy dates in ways that artificially tie them even more to the release cycle model followed by service deliverables
14:47:40 <ttx> so maybe it's that bundling that people are uncomfortable with
14:47:52 <dhellmann> fungi : nor am I
14:47:56 <dims> and use the release boundary as the duration of their super powers
14:48:11 <anteaya> I think people are uncomfortable with change, any change
14:48:15 <dhellmann> ttx: maybe we should define the problem in more detail, like you just did
14:48:28 <ttx> dhellmann: also a lot of people think of the proposal as "change" while it merely explain s what the future will look like unless we change the charter
14:48:35 <anteaya> we have so much change that I think we as a group have reached a limit of being able to accept it as a group
14:48:53 <dhellmann> ttx: yeah
14:49:00 <anteaya> that doesn't mean that we can't change just that we seem to be losing more and more folks with every change
14:49:05 <ttx> that is, the ball is not in our court
14:49:43 <ttx> dhellmann: at this stage people spread so much confusion on this I feel like any more explanation would only add to the confusion
14:49:52 <dhellmann> ttx: right, that's what I mean by define the problem better -- let the teams think about what is going to happen a bit and then see if the solution is more palatable
14:50:01 <ihrachys> anteaya: maybe. engineers know how to operate in current framework, we are comfortable with the current mode of operation.
14:50:06 <dhellmann> ttx: maybe we just drop it for now, then
14:50:27 <anteaya> ihrachys: well I think that people have decided to refuse to make the effort
14:50:27 <dims> since teams can do this already, we should position this as something we learned in some projects (say Nova) and we would like other projects to consider, i think
14:50:28 <ihrachys> ttx: I would consider that a bug in split proposal that we have not synced the current wording to reflect the status quo.
14:50:37 <anteaya> ihrachys: and are encouraging others to do the same
14:50:51 <dhellmann> dims : right
14:51:06 <ttx> "split proposal" ? You mean Ocata release schedule ?
14:51:20 <anteaya> ihrachys: there is no status quo having a ptg is new
14:51:21 <ihrachys> ttx: status quo being - ptls are getting in power on release boundary
14:51:42 <ihrachys> ttx: I mean split summit proposal, sorry
14:51:47 <persia> Rather than explicit release stewards, you might set expectations of the PTL (or a delegate) to cover the broken cycle, with the expectation that many projects will choose overlapping delegates to avoid confusion as things develop.
14:51:56 <ttx> ihrachys: that never was the status quo... PTLs are getting in power a number of weeks before the "Summit" event
14:52:09 <ttx> Now that might have been a silly rule
14:52:14 <ihrachys> ttx: you get what I mean. :)
14:52:15 <anteaya> persia: I think the phrase broken cycle is inaccurate, nothing is broken
14:52:23 <dhellmann> persia : yeah, that's what I mean by defining the problem better and letting the teams have time to see this as a reasonable solution
14:52:26 <persia> So that if someone who didn't meet with PWG/Ops, etc. became PTL, they would rely on the prior delegate/PTL, etc.
14:52:56 <persia> anteaya: I'm happy with "misaligned" if you prefer :)
14:53:26 <anteaya> persia: different, new?
14:53:44 <dhellmann> so, did we agree to let this wait for now? or do we need to take some more specific action?
14:54:02 <persia> anteaya: I specifically meant that release cycles no longer match election cycles.  My words are not intended to be part of the debate over PTG.
14:54:02 <ttx> ihrachys: would you support sdague's proposal, which is that PTL get i power 3 months after their election ? That's a simpler change to make
14:54:28 <ttx> that way " ptls are getting in power on release boundary"
14:54:58 <ttx> i.e. without making the term of people we'll elect starting today only 4 months
14:55:01 <ihrachys> ttx: would syncing the current wording on election dates with what we had before (-2weeks from release boundary) as first step, and then discussing a *change* to elect them at the time of summit separately be a possible path forward? or you stick to the idea that the ball is on dev side to introduce a change to keep the current mode of operation?
14:55:30 <anteaya> persia: okay well it is tough to get 'release cycles no longer match elections cycles' into a word or shorter phrase, I agree
14:55:42 <ihrachys> ttx: we can discuss time (I feel 3months is too much for 6months cycle), but yeah, I generally agree with the idea of giving some more time for transition.
14:55:47 <fungi> worth noting, having the election happen half a cycle before the effective date of office extends the commitment for a ptl candidate term by ~50%
14:56:25 <dhellmann> fungi : good point
14:56:26 <persia> It also complicates expectations of org management when approving or denying a request to stand for election.
14:56:32 <fungi> so instead of knowing you can carve out the next 6 months to serve as ptl, you'll now need to know you can be available 9 months out
14:56:52 <dhellmann> we're about out of time
14:56:55 <fungi> i don't know whether or not that's significant for most teams, but for those who rotate ptls often it might be
14:56:56 <ttx> ihrachys: that "syncing" must be proposed by someone.
14:57:20 <ihrachys> fungi: at the same time, it gives elected folks some time to wrap up their current affairs. the way it is now, we basically ask to commit themselves TOMORROW *if* they are elected.
14:57:27 <ttx> ihrachys: it would in effect align elections with "release boundary" (which would need to be defined)
14:58:00 <fungi> ihrachys: agreed. though i feel like in most projects people know who's going to run for ptl and have time for them to get up to speed on the duties before they self-nominate
14:58:00 <dhellmann> yay, making release scheduling even harder
14:58:02 <ttx> ihrachys: just feels weird to run elections starting today and not knowing when people will be repleaced.. in February or Apil.
14:58:04 <ttx> April
14:58:13 <dhellmann> "we can't have the release then, because that puts the election on a major holiday week"
14:58:29 <ttx> dhellmann: oh yes, fun
14:59:20 <dhellmann> ok, I think we've said all we can on that in the meeting
14:59:31 <dhellmann> thank you, everyone!
14:59:36 <ttx> FTR I don't care that much about PTL election date... only that we ahve people attached to release cycle
14:59:42 <ttx> to act as contact points
14:59:48 <dhellmann> agreed
15:00:07 <dhellmann> see you in #openstack-release
15:00:10 <dhellmann> #endmeeting