Earlier  
Posted Nick Remark
#openstack-nova - 2019-10-03
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
15:57:14 mriedem and my world for 2 years
15:57:23 efried thanks
15:57:39 mriedem yo'ure also very handsome
15:58:25 gmann efried: i have re-proposed the policy spec for ussuri - https://review.opendev.org/#/c/686058/
16:02:26 efried mriedem: is that a thing? Three thank-yous and the bot automatically picks it up?
16:02:34 efried I'll have to be more careful.
16:02:36 efried gmann: ack
16:02:46 mriedem efried: ha, no
16:02:51 mriedem not what i meant
16:03:24 efried gmann: stay tuned for an update on how we're going to be deciding on approvals (once we figure it out ourselves...)
16:06:00 gmann efried: you mean the on ML thread ? but this is re-proposal of already approved spec
16:06:54 efried gmann: yup, that's understood. We're leaning towards making even those conform to the same criteria.
16:07:12 gmann humm
16:08:05 efried gmann: mriedem makes a good point about needing to update the nova-specs readme accordingly, because previously-reviewed specs will need more than just a random single-core +2 now.
16:08:15 gmann I thought re-approved things are fast approved one and new one goes into that criteria
16:08:46 efried gmann: not an unreasonable assumption. We're still working out the details.
16:09:52 dansmith gmann: that's being changed
16:09:56 dansmith well, potentially
16:10:25 dansmith efried: fwiw, I think the re-approval of specs has always been flawed because we just kick things down the road instead of requiring them to muster enough support to be approved again
16:10:28 cdent if a pre-approved spec didn't get done in the previous cycle, one would think that it deserves extra inspection to see if it is maybe a lost cause
16:10:39 cdent yeah, what dansmith said
16:10:42 efried ++
16:10:42 dansmith yup
16:11:08 efried requiring the sponsor to +2 might be enough
16:11:59 efried or we could just completely do away with official special treatment, understanding that previously-approved specs will probably require less technical scrutiny just naturally.
16:17:11 mriedem dansmith: i hope i answered your question in https://review.opendev.org/#/c/686047/ and the one after it
16:23:44 dansmith mriedem: not really, but doesn't matter
16:24:55 SonPham hi

Earlier   Later