| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 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 | |
| 15:46:53 | mriedem | on the other hand, i could approve some non-core newb contributor but not sponsor them and absolve myself of all review responsibility | |
| 15:47:13 | mriedem | and thus being quite a dick | |
| 15:47:40 | efried | sure, I'm not trying to create a process to prevent dickishness. | |
| 15:47:43 | openstackgerrit | Dan Smith proposed openstack/nova master: Add reserved schema migrations for Ussuri https://review.opendev.org/686411 | |
| 15:47:48 | mriedem | in reality i just wouldn't approve the spec | |
| 15:47:52 | mriedem | if i don't intend to review it | |
| 15:48:16 | dansmith | that's what I'm hearing, | |
| 15:48:20 | efried | We need more than one reviewer (hopefully more than two, but I'm a realist) to approve code anyway. | |
| 15:48:27 | dansmith | and I think it's important to make sure all the cores get that message | |
| 15:49:01 | efried | If we had some way of making that message clear and making it stick, I would be all over it. | |
| 15:49:46 | mriedem | it probably needs to at least be documented in the specs review for code review process | |
| 15:49:52 | mriedem | *specs repo | |
| 15:50:33 | mriedem | https://specs.openstack.org/openstack/nova-specs/readme.html#specification-review-policies | |
| 15:52:14 | mriedem | i have voted on the liaison patch forewith | |
| 15:52:18 | mriedem | forthwith? | |
| 15:52:26 | mriedem | yes | |
| 15:55:31 | efried | thanks | |
| 15:57:06 | mriedem | btw i know this isn't fun, | |
| 15:57:08 | mriedem | welcome to process land | |