| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 15:22:26 | dansmith | I'm not trying to be too demanding, I just think we need to figure out what this process is if we're going to do it, | |
| 15:22:31 | mriedem | specs/ussuri/foreplay/ | |
| 15:22:52 | dansmith | because if I got my spec in the approved directory and then it gets ripped out later I'm going to be more confused than any of your bullets in your commit message :) | |
| 15:22:57 | efried | approving "definition" means "if we're going to do this, this is how we're going to do it"; approving "direction" means "we're going to do it, now" | |
| 15:23:21 | mriedem | i think i've been out-processed for once | |
| 15:23:26 | mriedem | gold star | |
| 15:23:29 | dansmith | okay so we're going to gate the real approval in launchpad? | |
| 15:24:03 | dansmith | and any code that makes it in before the spec freeze is golden, and then we make the 25 cut at spec freeze time of things that aren't done? | |
| 15:24:14 | efried | dansmith: I agree. Ideally I would like to have left all specs and bps unapproved until cut time, and the only merge the ones above the line. But since we've already merged some, that's messy. | |
| 15:24:30 | dansmith | efried: well, unmerge them if you want | |
| 15:24:48 | dansmith | but yes, this is sounding pretty messy one way or the other | |
| 15:25:20 | efried | yeah, thought about that too. stephenfin has code proposed for nova-net removal; we could merge some and then if that bp doesn't make the cut... in that case probably nbd to have partially done. | |
| 15:26:10 | stephenfin | in nova-net case, we've removes parts of it for a few cycles now | |
| 15:26:13 | efried | mriedem: Sigh, yeah, I continue trying to figure out how to make it as process-lite as possible. | |
| 15:26:26 | stephenfin | removing things like the os-fping API in past releases | |
| 15:26:45 | stephenfin | that doesn't apply to everything though, of course | |
| 15:27:12 | dansmith | efried: I guess my point is, this is not going to be better for visibility to the contributors if it seems like we're figuring out the rules as we go, and things drag on as late as spec freeze | |
| 15:27:14 | efried | dansmith: but yes, quite seriously, if we can get some kind of consensus that we're going to do this thing (even if the actual number is still open for negotiation), I could go unapprove everything. | |
| 15:27:24 | dansmith | efried: so being upfront with them is good, but let's not have that backfire | |
| 15:28:08 | dansmith | efried: okay, so if we do that, can I still land code for my spec that has not been approved? normally we would try to avoid that.. landing code until the design is accepted | |
| 15:28:40 | dansmith | efried: or do you want some sort of half-approval for the design but not the schedule or something? | |
| 15:29:29 | efried | good questions, Daniel-san | |
| 15:29:42 | efried | so | |
| 15:29:54 | dansmith | not trying to be a dick, just thinking through this for my own spec | |
| 15:30:01 | efried | totally, much appreciated. | |
| 15:30:12 | sean-k-mooney | if the feature merges before we do the cut maybe we jsut ingore it for quota | |
| 15:30:23 | mriedem | spec freeze is feb 13 so yeah... | |
| 15:30:26 | dansmith | sean-k-mooney: that's not the only question | |
| 15:30:28 | mriedem | that's a long time to be figuring things out | |
| 15:30:32 | dansmith | right | |
| 15:30:47 | sean-k-mooney | mriedem: ah cool so its m2 not m1 | |
| 15:30:56 | efried | even for approved blueprints and specs, we have a kind of all-or-nothing criterion we apply, where if it's important, we block the whole series until it's done. Otherwise (things like mox/nova-net/consoleauth removal etc) we allow partial as we go along. | |
| 15:31:00 | efried | so | |
| 15:31:07 | mriedem | so.. if cross-cell resize is unapproved, does that mean none of it can be approved code-wise until after spec freeze? | |
| 15:31:27 | dansmith | mriedem: that can't work, of course | |
| 15:31:34 | mriedem | cross-cell resize is not totally blocked, | |
| 15:31:39 | efried | we can do "definition approved" but "direction pending" until cut date, and things that can go partial can be merged during that time. | |
| 15:31:43 | mriedem | the switch is flipped at the n-1 patch in the series | |
| 15:31:52 | efried | and if we decide to cut that one, we just stop merging those | |
| 15:32:04 | sean-k-mooney | efried: would that not force most code to merge between m2 and m3 | |
| 15:32:08 | efried | that way work can continue while we're in planning limbo. | |
| 15:32:16 | sean-k-mooney | which is the opisite of what you want | |
| 15:32:31 | dansmith | efried: so we land the spec in approved, but the direction field in LP is the "are you in the critical quota" indication? | |
| 15:32:58 | efried | that would work, yah? | |
| 15:33:53 | dansmith | it's quite a departure from our process where most people totally ignore launchpad, so we just need to document it and raise the alarms so people know | |
| 15:34:03 | efried | ++ | |
| 15:34:05 | mriedem | what would storyboard do... | |
| 15:34:11 | dansmith | heh | |
| 15:34:16 | dansmith | mriedem: take storyboard with you | |
| 15:35:00 | dansmith | efried: so, the spec still gets a core sponsor field in this case? because launchpad has lots of other fields we could use instead | |
| 15:35:23 | dansmith | efried: and that might help decouple the "am I sponsoring this spec for review or...?" question | |
| 15:35:45 | efried | dansmith: Yes, I would like core sponsor in the spec to stay, because it's more indelible than lp | |
| 15:36:08 | efried | also I see lp as more of an administrative tool and the spec as more of a technical thing | |
| 15:36:21 | efried | i.e. devs should be able to ignore lp for the most part | |
| 15:36:42 | dansmith | okay, so then I need to consider whether I'm going to sponsor a thing now when it lands, in anticipation that it may be chosen for the top 25 later and I'll be on the hook to review it in that case? | |
| 15:36:51 | efried | yes | |
| 15:37:29 | efried | and btw, that could inform how you vote for what gets cut | |
| 15:37:29 | dansmith | okay so I will still be conservative with what I'm willing to sponsor in spec reviews | |
| 15:38:17 | efried | dansmith: that's a legit approach. It ought to end up limiting the number of things on the table at cut time, which is productive in itself. | |
| 15:39:01 | mriedem | are we still confusing sponsor with on the hook to review? | |
| 15:39:16 | dansmith | aight, so artom you need to get your tests landed so you can get your spec up so I can shoot my wad on it | |
| 15:39:18 | mriedem | i keep getting confused if those are meant to be the same | |
| 15:39:21 | efried | mriedem: not confusing. That's one of the stated purposes of sponsor | |
| 15:39:36 | mriedem | then...why don't we have sponsors for core-proposed specs? | |
| 15:39:41 | artom | dansmith, what your what on my what now? | |
| 15:39:43 | mriedem | i.e. i can't review and +2 my own changes | |
| 15:39:46 | dansmith | efried: don't say it's not confusing because it has confused at least two of us already | |
| 15:40:02 | mriedem | there are really 2 things: | |
| 15:40:06 | dansmith | artom: spec for sriov LM claims | |
| 15:40:06 | artom | dansmith, you mean land the NUMA LM func tests so that I can propose the SRIOV LM Claims spec? | |
| 15:40:07 | mriedem | 1. official hand holder | |
| 15:40:11 | dansmith | artom: cha | |
| 15:40:13 | mriedem | 2. designated reviewer | |
| 15:40:28 | artom | dansmith, ok, I guess that answers my question of whether we need a spec for it :) | |
| 15:40:41 | mriedem | sponsor is munging both of those concepts it seems | |
| 15:40:54 | dansmith | artom: I was going to say in the meeting I think it's worthwhile, but this process also tells me that you need a spec in order for me to document that I want to spend my time reviewing it | |
| 15:40:55 | mriedem | and #2 doesn't jive with "i'll sponsor my own spec thanks" | |
| 15:41:18 | artom | dansmith, oh i c | |
| 15:41:55 | dansmith | mriedem: Designated Reviewer is a new series on ABC this fall starring Keifer Sutherland | |
| 15:42:09 | mriedem | as long as it's not cop drama on cbs | |
| 15:42:14 | mriedem | NDISLKD | |
| 15:42:34 | artom | CSI: Gerrit | |
| 15:42:36 | efried | mriedem: There's nothing stopping a core from having a separate sponsor. I just didn't want to make it a hard requirement that owner != sponsor. Because cores (and experienced nova devs) know how to go ask for reviews, so they don't need it written down. | |
| 15:43:04 | efried | mriedem: I agree it would be nice to have someone on the hook committed to reviewing your thing. | |
| 15:43:23 | mriedem | so how is sean-k-mooney a sponsor on his own spec in your liaison patch? | |
| 15:43:34 | mriedem | i guess for the same reason dan is on his? | |
| 15:43:37 | mriedem | i'm still confused | |
| 15:43:39 | mriedem | but whatever | |
| 15:43:48 | mriedem | it's nearly 11am and i haven't done anything useful | |
| 15:43:51 | efried | artom suggested that experienced devs are culturally indoctrinated enough to know how to go ask for reviews. | |
| 15:44:03 | efried | I updated the template language accordingly | |
| 15:44:18 | dansmith | efried: so then sponsor is not the designated reviewer but the designated "tell them to ask for reviews" person? | |
| 15:44:32 | mriedem | i'm hearing it's .... both? | |
| 15:44:35 | efried | "help me get this reviewed" | |
| 15:44:37 | mriedem | but only on thursdays | |
| 15:45:20 | efried | Also noting that reviews from experienced devs are valuable even if they aren't able to approve | |
| 15:45:48 | mriedem | examples would be good for thinking through this, | |
| 15:46:14 | mriedem | so on dan's spec, if i am listed as an official sponsor, it's not because i need to hold dan's hand, it's because i'm signing up to be an official reviewer feet to the fire person | |
| 15:46:25 | mriedem | and he has all rights to harass me in irc if i do'nt do so | |
| 15:46:37 | efried | yes | |