| SlickNik | ttx: https://review.openstack.org/156486 has merged now. 71376d4e486d12d77622e43ad5161a7e22b2ddc7 is the commit hash. Feel free to tag when you get a chance. Thanks! | 02:21 |
|---|---|---|
| ttx | tagging nova first | 07:24 |
| ttx | nova and trove tagged | 07:48 |
| ttx | flaper87: shall we cut a k3 for zaqar ? | 08:24 |
| *** zz_johnthetubagu is now known as johnthetubaguy | 09:25 | |
| johnthetubaguy | ttx: thanks for your work on this one, sorry it was down to the wire again | 09:30 |
| ttx | johnthetubaguy: with 11+ projects there is always a few stragglers | 10:02 |
| johnthetubaguy | ah, true I guess | 10:03 |
| sdague | ttx: I assume we're at requirements freeze now right? | 11:02 |
| sdague | I've started -2ing some patches for that reason, but realized I should double check | 11:02 |
| ttx | sdague: yes | 11:02 |
| sdague | ok, I'm providing the following message in commits | 11:02 |
| sdague | "We are in requirements freeze until all integrated projects have stable branches. Only high priority bug fixes are appropriate until then." | 11:02 |
| ttx | sdague: until all projects reach RC1 at least | 11:02 |
| ttx | yep | 11:03 |
| asalkeld | speaking of deps | 11:03 |
| asalkeld | ttx can we add a dependency on oslo.concurrency? | 11:03 |
| asalkeld | is oslo and clients still ok? | 11:03 |
| ttx | asalkeld: why is it needed ? | 11:03 |
| ttx | generally version bumps are ok, new deps are not | 11:04 |
| asalkeld | https://review.openstack.org/#/c/165396/4 | 11:04 |
| asalkeld | just to set a sensible worker count | 11:04 |
| ttx | although oslo.* is lower friction (assumed packaged already) | 11:04 |
| asalkeld | better that something hardcoded | 11:04 |
| asalkeld | not a big deal tho' | 11:04 |
| ttx | I think it's worth proposing it as an exception... | 11:05 |
| sdague | ttx: you want to allow version bumps still? I was freezing everything without a bug | 11:05 |
| asalkeld | ttx: email to -dev? | 11:05 |
| ttx | sdague: bumps that correspond to latest oslo/client releases were accepted in the past | 11:06 |
| sdague | ttx: ok, why don't we back up. What do you consider freezing on the requirements side so I don't do this wrong | 11:06 |
| ttx | basically, if some oslo library "kilo" version is bumped post-FF (rare) then it sounds ok to me to let that trickle down | 11:07 |
| asalkeld | sdague: sorry for butting in, I'll come back later to chat to ttx | 11:07 |
| sdague | asalkeld: no worries | 11:07 |
| sdague | ttx: ok | 11:07 |
| ttx | sdague: basically it's a dep freeze, not a requirements freeze | 11:07 |
| sdague | I think I blocked some client bumps already | 11:07 |
| ttx | we want to preserve downstream from last-minute packaging of new deps | 11:08 |
| ttx | but we still want downstream to bump oslo libs and client libs if we update the "kilo" version for those | 11:08 |
| sdague | ok | 11:08 |
| sdague | so exclude python- and oslo at this point | 11:08 |
| ttx | oslo libs all have stable branches now, so they should have been bumped already | 11:08 |
| sdague | but like https://review.openstack.org/#/c/164289/1/global-requirements.txt,cm would still be blocked | 11:08 |
| ttx | it shoudl at very least require exception yes | 11:09 |
| ttx | i.e. is the pain we inflict balanced by the criticality of the bug | 11:09 |
| ttx | so in summary: | 11:09 |
| ttx | - bumps corresponding to new "kilo" releases of client or oslo or middleware: YES | 11:10 |
| ttx | - bumps for existing, external dependencies: MAYBE, if bugfix worth it | 11:10 |
| ttx | - new dependencies: NO (except very extreme cases where the new dep is required to fix a critical bug) | 11:11 |
| ttx | sdague: does that make sense ? Any case I don't cover ? | 11:11 |
| ttx | (I never formalized it this way before so I might just be wrong) | 11:11 |
| ttx | asalkeld's case falls out of the map, it's a new *oslo* dep | 11:12 |
| asalkeld | yeah a bit of a grey area | 11:12 |
| ttx | it could be assumed being packaged already... or assumed being a new dep | 11:12 |
| sdague | well, it's not new in the openstack space | 11:12 |
| sdague | when do we have a *hard* no? | 11:13 |
| asalkeld | should be easy enough for a packager to deal with | 11:13 |
| sdague | because there is also pipeline lag in projects picking up the requirements updates | 11:13 |
| asalkeld | (in my case) | 11:13 |
| sdague | asalkeld: yeh, honestly, I think heat adding an existing oslo lib should be kosher | 11:13 |
| ttx | sdague: when the new dep is triggered by a new feature for some non-integrated project that doesn't follow FF | 11:13 |
| ttx | I would say that's a hard "NO, WAIT" | 11:14 |
| sdague | ttx: right, but so even client bumps, for instance | 11:14 |
| sdague | one of the reasons to freeze is that getting projects to merge the requirements patches takes time | 11:14 |
| ttx | sdague: yeah, I'd say that's kosher | 11:14 |
| sdague | so you have to anticipate 2 weeks to get to convergence | 11:14 |
| ttx | maybe brand-new libs would be a bit different | 11:15 |
| sdague | which means anything we let through now, we have to be ok that there is a 2 week lag until it's in the projects | 11:15 |
| ttx | but existing libs already used somewhere... kosher | 11:15 |
| * ttx adds to https://wiki.openstack.org/wiki/DepFreeze | 11:15 | |
| ttx | sdague: please review https://wiki.openstack.org/wiki/DepFreeze | 11:18 |
| ttx | sdague: want me to help on the massive -2ing, or you have it covered ? | 11:20 |
| ttx | asalkeld: so I think we can approve your oslo lib addition | 11:21 |
| ttx | sdague: the other idea behind depfreeze is to ensure we propagate to projects (merge the req bot proposal) before tagging RC1 | 11:22 |
| ttx | If we keep on modifying the requirements file it's harder :) | 11:22 |
| sdague | https://etherpad.openstack.org/p/requirements-freeze | 11:23 |
| ttx | Also removals are generally OK | 11:23 |
| ttx | I should add that | 11:23 |
| sdague | so the wiki page isn't working for me | 11:23 |
| sdague | in the kind of decision making I'm doing | 11:24 |
| sdague | so lets look at the etherpad | 11:24 |
| sdague | because I think there are 3 freeze phases | 11:24 |
| sdague | and we can map them back to dates later | 11:24 |
| ttx | why 3 phases ? | 11:24 |
| ttx | or 4 | 11:25 |
| sdague | because at some point you have to stop | 11:25 |
| sdague | and the risk is different for each of these kinds of changes | 11:25 |
| ttx | so I think I agree with what you're saying: I'm just using the exception process to include time as a factor | 11:26 |
| ttx | (same for all kind of exceptions) | 11:26 |
| sdague | so everything is a -2, and then treated as exceptions with bugs? | 11:26 |
| sdague | basically we're already at phase 3? | 11:26 |
| sdague | I'm ok with that as well | 11:27 |
| sdague | I guess that's my question | 11:27 |
| ttx | We could do two phases | 11:27 |
| ttx | Your (1) | 11:27 |
| ttx | err | 11:27 |
| ttx | Your(2) and your (4) I think | 11:27 |
| sdague | I actually think if we go to 2 phases it's 1.5 & 3 | 11:27 |
| sdague | yeh | 11:27 |
| ttx | 1.5 / 3 right | 11:28 |
| sdague | so if 1.5 is now, when does 3 kick in? | 11:28 |
| ttx | Basically at one point it's a hard freeze because we need to propagate the final files | 11:28 |
| ttx | when people start to cut RC1s, which is a bit fuzzy | 11:28 |
| ttx | the way we did it before is stop granting exceptions when we near RC1s | 11:28 |
| sdague | except, if we propogate a fix, we need to let it converge | 11:28 |
| sdague | so it might require another oslo lib release | 11:29 |
| ttx | so that we get the final requierments update in every project | 11:29 |
| sdague | if you want real convergence, you need to hard freeze now :) | 11:29 |
| ttx | yeah, it's always been a bit of a chase | 11:29 |
| sdague | my recommendation is that hard freeze is no more than 2 weeks after dep freeze | 11:30 |
| ttx | sounds good | 11:30 |
| sdague | but 1 week is probably better | 11:30 |
| ttx | At one point the oslo bumps craete disruption that we need to balance with the bugfix impact | 11:30 |
| ttx | and that starts 1.5 weeks in Depfreeze | 11:31 |
| ttx | so we need an exception process to analyze that balance | 11:31 |
| ttx | So its more like a ExternalDepFreeze and AllDepFreeze | 11:32 |
| ttx | We give them a week to push internal deps/bumps in post-FF | 11:32 |
| ttx | and then switch to all-exceptions | 11:32 |
| ttx | sdague: that would correspond to waht we did in the past informally | 11:33 |
| sdague | ok, sound reasonable. You want to wikize that | 11:33 |
| ttx | need to run for lunch, will wikize that | 11:33 |
| sdague | also, the yes/no table is really helpful for me to think about things, would appreciate that in the wiki | 11:33 |
| ttx | maybe call it DepFreeze and AllDepFreeze | 11:34 |
| ttx | so that we preserve backward compat | 11:34 |
| ttx | willdo | 11:34 |
| sdague | DepFreeze and HardDepFreeze honestly | 11:35 |
| sdague | ttx: ok, I just ran through - https://review.openstack.org/#/q/project:openstack/requirements+status:open,n,z and -2ed / +2ed most things based on that 1.5 table | 11:42 |
| sdague | test requirements version bumps and client/middleware bumps allowed, -2 to all others | 11:43 |
| sdague | there is a lot outstanding, so if I could get you and/or dhellmann to run the whole list and flush things, that would be appreciated | 11:43 |
| sdague | and call me out where I -2ed incorrectly | 11:43 |
| *** mestery is now known as mestery_afk | 11:45 | |
| *** asalkeld has quit IRC | 11:55 | |
| ttx | ok wikied | 12:44 |
| ttx | looking at the list now | 12:45 |
| ttx | done a pass. Would be good to have dhellmann do another son | 12:58 |
| ttx | soon | 12:58 |
| ttx | then we could quickly discuss the remaining corner cases | 12:58 |
| sdague | ok, works for me. | 14:00 |
| sdague | I have a phone call now, but I'd be up for doing an interactive session in an hour | 14:00 |
| *** dansmith is now known as superdan | 14:03 | |
| *** mestery_afk has quit IRC | 14:19 | |
| *** mestery has joined #openstack-relmgr-office | 15:15 | |
| *** david-lyle_ has joined #openstack-relmgr-office | 16:50 | |
| *** david-lyle_ has quit IRC | 16:51 | |
| *** johnthetubaguy is now known as zz_johnthetubagu | 18:25 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!