| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-03 | |||
| 15:12:44 | efried | Since it was, like, your idea | |
| 15:12:58 | efried | (I know, I know. But still.) | |
| 15:15:05 | dansmith | efried: uh, wut | |
| 15:15:37 | dansmith | oh you mean I said something in a PTG a year ago? | |
| 15:15:42 | efried | yes | |
| 15:15:48 | efried | you can't un-say it | |
| 15:15:57 | mriedem | cdent: correct | |
| 15:15:59 | efried | it was more like six months ago | |
| 15:16:08 | efried | statute of limitations | |
| 15:16:18 | dansmith | sure, but just because I think that's the way it should be done if we're going to do it, doesn't mean I think we should or that I want to put my neck out there for it, right? | |
| 15:17:22 | dansmith | I guess it depends on whether we tie the sponsorship thing purely to "help the contributor with the process" or "I plan to review this myself" | |
| 15:18:01 | efried | yeah, good point; I would definitely like you to be involved in the reviews; I'm mentoring dustinc either way. | |
| 15:18:04 | dansmith | I'll look it over and see what I think, but I kinda feel like I want to know what the ratelimiting number is going to be before I decide what I'm going to throw my support behind | |
| 15:18:09 | efried | (and reviewing the code either way) | |
| 15:18:49 | efried | dansmith: fair, though for simplicity, it may help to keep those things mentally separate. You can sponsor a thing, but it could still fall off the bottom at spec freeze time. | |
| 15:19:28 | dansmith | efried: not at spec freeze time, but at the "what are the top 25 things" point right? | |
| 15:19:51 | sean-k-mooney | that i would expect to be around ptg time | |
| 15:20:03 | sean-k-mooney | or just after ptg but before spec freeze | |
| 15:20:14 | dansmith | neither of us are going to be at ptg, so... | |
| 15:20:19 | mriedem | efried: comments on https://review.opendev.org/#/c/685857/ | |
| 15:20:30 | efried | dansmith: yes, I was thinking spec freeze time would be when we do the cut | |
| 15:20:39 | efried | but tbd | |
| 15:20:41 | dansmith | efried: wait, what? | |
| 15:21:04 | dansmith | efried: so we're going to put a bunch of specs in and then draw some line and what, remove the ones that aren't above the line? | |
| 15:21:18 | dansmith | maybe we need a different directory for almost-approved ? :) | |
| 15:21:41 | dansmith | btw, | |
| 15:21:44 | efried | yeah, something like that; if they're still unapproved we leave them unapproved (abandon, propose to backlog, whatever) and if they're already approved in the specs repo, we pull them out (and shunt them to backlog or whatever) | |
| 15:22:04 | dansmith | we should put them not in the approved directory then, IMHO | |
| 15:22:07 | dansmith | and btw, | |
| 15:22:15 | efried | this is probably why "direction" and "definition" are different fields in lp | |
| 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 | dansmith | okay so I will still be conservative with what I'm willing to sponsor in spec reviews | |
| 15:37:29 | efried | and btw, that could inform how you vote for what gets cut | |
| 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 | artom | dansmith, you mean land the NUMA LM func tests so that I can propose the SRIOV LM Claims spec? | |
| 15:40:06 | dansmith | artom: spec for sriov LM claims | |