| *** hongbin has quit IRC | 00:23 | |
| *** sdague has quit IRC | 00:55 | |
| *** kumarmn has joined #openstack-tc | 01:37 | |
| *** gcb has joined #openstack-tc | 01:42 | |
| *** mriedem has quit IRC | 01:54 | |
| *** kumarmn has quit IRC | 02:09 | |
| *** kumarmn has joined #openstack-tc | 02:09 | |
| *** kumarmn has quit IRC | 02:30 | |
| *** kumarmn has joined #openstack-tc | 02:30 | |
| *** kumarmn has quit IRC | 02:35 | |
| *** rosmaita has quit IRC | 04:15 | |
| *** kumarmn has joined #openstack-tc | 04:38 | |
| *** kumarmn has quit IRC | 04:43 | |
| *** mtreinish has quit IRC | 06:55 | |
| *** mtreinish has joined #openstack-tc | 06:55 | |
| *** kumarmn has joined #openstack-tc | 07:31 | |
| *** kumarmn has quit IRC | 07:36 | |
| openstackgerrit | Rabi Mishra proposed openstack/governance master: Add heat-tempest-plugin repo https://review.openstack.org/519578 | 08:17 |
|---|---|---|
| *** jpich has joined #openstack-tc | 08:57 | |
| * johnthetubaguy waves hello to folks who have returned from syd (and those who are still here from before) | 08:58 | |
| * gcb waves | 09:10 | |
| *** zaneb has quit IRC | 09:54 | |
| *** sdague has joined #openstack-tc | 10:32 | |
| *** dtantsur|afk is now known as dtantsur | 11:20 | |
| *** kumarmn has joined #openstack-tc | 11:31 | |
| *** kumarmn has quit IRC | 11:36 | |
| *** rosmaita has joined #openstack-tc | 13:01 | |
| *** kumarmn has joined #openstack-tc | 13:32 | |
| *** kumarmn has quit IRC | 13:35 | |
| *** mriedem has joined #openstack-tc | 13:59 | |
| *** kumarmn has joined #openstack-tc | 14:33 | |
| dims | o/ | 14:50 |
| * smcginnis is back home and catching up | 14:57 | |
| *** zaneb has joined #openstack-tc | 14:58 | |
| *** hongbin has joined #openstack-tc | 15:20 | |
| *** zaneb has quit IRC | 15:21 | |
| *** chandankumar is now known as chkumar|upgrade | 15:37 | |
| *** zaneb has joined #openstack-tc | 15:43 | |
| *** dtantsur is now known as dtantsur|brb | 15:46 | |
| openstackgerrit | Emilien Macchi proposed openstack/governance master: Remove stable:follows-policy from Kolla https://review.openstack.org/519685 | 15:51 |
| *** chkumar|upgrade is now known as chandankumar | 16:10 | |
| *** zaneb has quit IRC | 16:25 | |
| *** zaneb has joined #openstack-tc | 16:25 | |
| dims | folks, please peek at https://etherpad.openstack.org/p/LTS-proposal | 17:15 |
| pabelanger | will do | 17:16 |
| dims | thanks pabelanger | 17:16 |
| pabelanger | also, I've heard LTS might not be the right name a few times. Specifically the 'support' wording in LTS | 17:17 |
| TheJulia | dims: already open on a tab :) | 17:18 |
| dims | Thanks! | 17:18 |
| johnthetubaguy | LTS = Long Term Stable-branch ? | 17:21 |
| dtroyer | agreed on the 'maybe don't use the term "LTS" here', it's heavily influenced in prople's minds by the distro's usage | 17:21 |
| *** jpich has quit IRC | 17:21 | |
| dtroyer | ZR = zombie release, the occasional release that is kept alive 'forever', but without new releases, just 'alive' | 17:22 |
| dtroyer | s/alive/not dead/ | 17:22 |
| SamYaple | well in most things 'LTS' just means youll get security and critical bug fixes for a long time. that counts as 'support' | 17:27 |
| SamYaple | i like the way ceph does it. with an LTS once a year, and a new 'stable' every 6 months | 17:28 |
| SamYaple | with the intermediate 'stable' release not having long support at all (it basically EOLs as soon as the new LTS lands) | 17:28 |
| pabelanger | dtroyer: yah, zombie release is more the feedback I hear in hallways | 17:29 |
| *** dtantsur|brb is now known as dtantsur | 17:45 | |
| *** kumarmn_ has joined #openstack-tc | 19:33 | |
| *** kumarmn has quit IRC | 19:36 | |
| *** dtantsur is now known as dtantsur|afk | 19:45 | |
| dtroyer | SamYaple: it feels like that is our best bet for a small step forward, to get explicit about extending only specific releases, every 2nd or 3rd one or so | 20:04 |
| SamYaple | i like year long releases, all our cycles start to match up | 20:05 |
| SamYaple | *and* it lets us kind of target a general "bug fixy" release | 20:05 |
| SamYaple | more experimental stuff can goin the inbetween releases | 20:05 |
| SamYaple | give it some time to beused and stable-up | 20:05 |
| dtroyer | and all those clamoring for more rapid innovation will… ??? Will projects like Nova that are already fairly slow to change slow down more or will they feel like they have a chance to catch up? | 20:07 |
| SamYaple | well forthe "rapid innovation" nothing will change right? well be in the same situation, 2 releases a year | 20:08 |
| dtroyer | I think we have a perception that "more shorter release cycles" is that it helps drive things to completion, even multi-cycle things. is that still the case? | 20:08 |
| pabelanger | dtroyer: good question | 20:08 |
| SamYaple | i suspect the _perception_ might shift a bit, but the reality would be the same | 20:09 |
| smcginnis | Those that want things faster can deploy from master. (rhyme not intended) | 20:10 |
| SamYaple | or latest stable (which may ormay not be an LTS) | 20:10 |
| smcginnis | But I do think the shorter cycles do help drive things. | 20:10 |
| smcginnis | But at the same time, also causes us to compromise on some things to try to not make something a multi-release process. | 20:10 |
| dtroyer | smcginnis: careful, that'll become a catch phrase | 20:11 |
| smcginnis | ;) | 20:11 |
| SamYaple | i would like to avoid "no feature merges before LTS release" type attitude for sure. but weve talked about bugfix/stabilization cycles before. just the name LTS kind of gets people in that stabilization mindset without having to explicitly define one | 20:12 |
| dtroyer | it does feel to me that OpenStack is past the stage where rapid releases are useful and a one-year cadence of primary releases that are directly upgradeable would be welcome, with intermediate secondary releases in between to keep the bug fix flow going. | 20:13 |
| smcginnis | SamYaple: That certainly is a risk. | 20:13 |
| SamYaple | dtroyer: master with words, you are | 20:14 |
| smcginnis | dtroyer: I was thinking that earlier. At early stages, more rapid releases are probably more necessary just by the nature of a newly developed and rapidly changing project. But once things get to a point where they are mostly "stable", it is probably less of an issue. | 20:14 |
| dtroyer | SamYaple: it took me since that last session to put that together :) | 20:14 |
| SamYaple | i would suggest looking at the ceph release cycle and community perception. it strongly matches what weare discussing | 20:15 |
| SamYaple | plus ceph already sync'd its releases to openstack. so now wewould be syncing LTS releases :) | 20:15 |
| dtroyer | remember the odd/even minor version thing that the kernel did for a while? is it similar to that? (modulo the timing parts) | 20:16 |
| SamYaple | hmm probably best explained by this chart | 20:16 |
| SamYaple | moment | 20:16 |
| SamYaple | http://docs.ceph.com/docs/master/releases/ | 20:16 |
| SamYaple | though we wont need to neccesarily follow the deprecation stuff they do | 20:17 |
| SamYaple | i like our deprecation stuff mostly | 20:17 |
| SamYaple | luminous, jewel, hammer, firefly were the LTS releases inthat chart | 20:17 |
| dtroyer | ok, at a quick look the idea looks very similar, if not identical | 20:18 |
| SamYaple | except the deprecation stuff. thats an important thingto note | 20:18 |
| SamYaple | they EOL the stable-but-not-LTS brnach as soon as the newLTS is out | 20:19 |
| dtroyer | to put it into our terms, let's say the spring release (Queens now) is the primary release with a longer shelf life and the fall release (Rocky is next) is shorter. yes | 20:19 |
| SamYaple | would "shorter" be a 6 month deprecation vs the 12 month we have now? | 20:20 |
| SamYaple | (approx) | 20:20 |
| dtroyer | the goal that I would expect as an operator then is to be able to upgrade spring to spring (Q -> S), or spring to fall (Q -> R) and fall to next spring (R -> S) | 20:20 |
| dtroyer | that cuts the number of releases we need to upgrade test between | 20:20 |
| SamYaple | hmmm. thats not bad, but that wouldjust makeevery release LTS again | 20:21 |
| dtroyer | SamYaple: I think so, yes | 20:21 |
| SamYaple | ohnvm | 20:21 |
| SamYaple | ignore me, i misread | 20:21 |
| dtroyer | no, the fall release EOLs earlier, like you said | 20:21 |
| SamYaple | yea. ok then yes this wouldbe almost identical | 20:22 |
| SamYaple | and frankly, that cycle has worked pretty well overthe last 4 years or so of ceph | 20:22 |
| SamYaple | i sometimes move to a non-LTS, sometimes not depending on my needs | 20:22 |
| dtroyer | this puts no conditions on the contents of any given release (feature, bug-fix-focus, whatever), only on what we target for testing and expect for $UPSTREAM to manage over time | 20:22 |
| SamYaple | there is also no "conditions" on the ceph releases, but as it happens humans get involved and the work turns much more bug-fixy towards the end before an LTS release | 20:23 |
| SamYaple | thats not abad thing, but something to consider | 20:23 |
| dtroyer | I wondered if that would be a natural outcome | 20:24 |
| SamYaple | good chat, i gotta go fora bit. ill read scrollback to catch back up on any additional conversations regardingthis | 20:24 |
| dtroyer | thanks SamYaple, it helps me congeal the stuff still swirling around in my brain :) | 20:25 |
| dims | SamYaple : please throw a line proposal in https://etherpad.openstack.org/p/LTS-proposal if you wish. let's see how many folks will go for it. | 20:35 |
| openstackgerrit | Matthew Treinish proposed openstack/governance master: Update Python PTI for tests to be specific and explicit https://review.openstack.org/519751 | 20:43 |
| *** kumarmn has joined #openstack-tc | 20:48 | |
| *** kumarmn_ has quit IRC | 20:51 | |
| openstackgerrit | Matthew Treinish proposed openstack/governance master: Update Python PTI for tests to be specific and explicit https://review.openstack.org/519751 | 22:16 |
| SamYaple | dims: cool ill give it a look see what i can add | 22:35 |
| dims | Thanks SamYaple ! | 22:36 |
| *** kumarmn has quit IRC | 23:37 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!