Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-26
14:36:27 kashyap (And you can detect this "DMA32" thing by running `grep DMA /proc/zoneinfo` on the host.)
14:37:41 kashyap efried: And no, please remove that mouthguard - you _do_ make a good point: for someone to understand the mapping of bool to 'preferred'/'strict', it's needless gory details
14:38:11 kashyap I'll mull on it more and comment on the change.
14:38:23 kashyap Thanks for the input, both.
14:42:07 mriedem oh donnyd donnyd donnyd
14:42:12 mriedem you've opened a can of worms
14:42:29 donnyd Is it a good or bad can?
14:42:50 donnyd like fresh worms or worms that have been sitting in the sun for 3 weeks
14:44:11 mriedem moldy worms
14:44:33 mriedem i, of course, can't help but take that bait
14:44:38 donnyd LOL
14:45:11 donnyd Well they are just observations.. not saying anything is right, wrong.. indifferent..
14:46:56 mriedem it's fun to see how the sausage gets made though huh
14:47:25 donnyd its quite interesting from my perspective - i have been building these things for quite a long time
14:47:27 mriedem fwiw every closed source project i worked on before openstack was also a clusterf*ck
14:47:46 donnyd openstack isn't a charlie foxtrot.
14:47:46 mriedem come release time anyway
14:47:56 donnyd I don't think that is the case at all...
14:48:04 mriedem the thing i mostly enjoy is the foundation marketing that says "20 release ON TIME"
14:48:16 mriedem *releases
14:48:19 donnyd I just think humans have a tendency to delay until they cannot anymore
14:48:31 mriedem yup, i noted that in my reply
14:48:34 mriedem and that's our MO here as well
14:49:37 mriedem and the squeeky wheel gets the grease...
14:49:51 donnyd that is a true story in literally all things
14:51:08 mriedem i've left some squeeky hinges in my house go ungreased out of spite
14:51:17 donnyd I also think nobody consumes the milestones because they are perceived to be "beta"
14:51:22 mriedem "gdi i *just* greased you"
14:52:03 donnyd and maybe changing around the perception would increase the consumption
14:52:12 mriedem at this point in the game i don't think that's likely
14:52:45 mriedem if anything,
14:52:54 mriedem people have wanted to consume at a much slower pace as time as gone on
14:53:03 mriedem hence all the demands for LTS branches and stuff
14:53:12 donnyd hence the 9 month major cycle
14:53:17 donnyd or even 12 month
14:53:23 mriedem blech
14:53:33 mriedem we'll just wait until the last minute to cram even less stuff in :)
14:53:55 mriedem and,
14:54:06 mriedem it will be double the shit that someone has to consumer and grok from the release notes when they do
14:54:12 mriedem *consume
14:54:48 donnyd how is that different from say an ubuntu or centos release though?
14:55:19 donnyd centos/rhel
14:56:08 donnyd Also thank you for replying
14:56:28 mriedem i can't say how those distro dev cycles are different,
14:56:33 mriedem but i imagine there much more strictly controlled
14:56:36 mriedem *they're
14:57:18 mriedem and when rhel i'm paying a support license so i expect more rigor before the thing is released than just "here it is, here are the release notes, have fun"
14:57:21 mriedem *with rhel
14:57:23 mriedem man i can't type today
14:58:22 mriedem i'm also not sure how moving from 6 to 12 months cycles would go over with someone like vexxhost that does actually do proper CI/CD and doesn't wait 18 months before upgrading
14:58:39 mriedem kashyap: sure, whatever - "pay for play"
14:59:05 kashyap I need to first load up on the topic being discussed. (I've got the -discuss list open, with Donny's email)
15:00:56 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Handle legacy request spec dict in ComputeTaskManager._cold_migrate https://review.opendev.org/684407
15:01:54 kashyap donnyd: That's indeed a barrel of worms; it was discussed to nauseating levels. See this epic thread from 2015:
15:02:05 kashyap donnyd: "Re-evaluating the suitability of the 6 month release cycle" -- https://openstack.nimeyo.com/34284/openstack-dev-evaluating-suitability-month-release-cycle
15:02:17 kashyap donnyd: Before you click that, go fill up your giant mug of tea, I say.
15:02:20 donnyd mriedem: but vexxhost could surely make use of more often . releases
15:02:34 kashyap It's a long and worthwhile read. (Especially "looking back")
15:03:10 donnyd well to be fair... that was 4 years ago
15:03:36 kashyap donnyd: To get the tl;dr of suggestion, see "The modest proposal"
15:03:42 kashyap [quote]
15:03:43 kashyap Based on these observations I would suggest that OpenStack aim to
15:03:44 kashyap This will have a number of consequences which I'd expect to be
15:03:44 kashyap ie do 6 releases a year.
15:03:44 kashyap switch to a development cycle that is exactly 2 months long.
15:03:46 kashyap beneficial to the project on balance.
15:03:48 kashyap [/quote]
15:04:29 kashyap donnyd: 4 years ago, but many things wrote there apply perfectly well today.
15:06:19 donnyd but 4 years ago our community was probably 2x the size it is now wasn't it? (i wasn't here, so i can't actually quantify that)
15:06:32 mriedem lyarwood: we have a few open stable/stein changes that we could get in before the next release but i think the biggest ticket one ends at https://review.opendev.org/#/c/684407/ since that resolves an upgrade issue introduced in stien
15:06:35 mriedem dansmith: ^
15:07:03 mriedem donnyd: yes much bigger and much more diverse
15:07:04 kashyap donnyd: It _was_ larger; but shortening the cycle length applies even today.
15:07:27 kashyap donnyd: It reduces the: "hey, our distro is gonna be based on X upstream release, we _must_ shove our feature upstream in time!"
15:07:41 kashyap s/distro/"long-term OpenStack distro"/
15:07:54 kashyap (Among other things)
15:08:24 donnyd for the record.. I am happy either way
15:13:22 kashyap donnyd: Nod; but yes, as both of you said, it's the "human nature" element. And "planning is guessing". Go a "six-month plan"? Call it a "six-month guess".
15:13:25 kashyap (https://m.signalvnoise.com/planning-is-guessing/)
15:14:51 donnyd right... "everyone has a plan until they get punched in the mouth"
15:14:57 donnyd - mike tyson
15:15:48 donnyd so wouldn't the message there be create smaller plans??
15:16:19 openstackgerrit Walter A. Boring IV (hemna) proposed openstack/nova stable/pike: WIP: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008
15:17:29 mriedem donnyd: i think that's efried's plan for ussuri
15:17:44 mriedem i.e. only approve blueprints for things that were previously approved and not yet complete
15:18:08 kashyap donnyd: Yeah, smaller plans are fine - focus more on the unsexy, "boring" stability (don't-fall-apart-if-you-sneeze) and less of "features"
15:18:43 kashyap s/fine/preferred/ (ha, see what I did there :D)
15:21:58 kashyap donnyd: Fun fact I just learnt: Tyson actually _lost_ that match, after that quote (which he targeted at his oponnent, when a journalist asked "if you're worried about his plan") :D
15:22:00 donnyd Well the cycle time would just be broken up differently.. I wouldn't think the major release cycle time would be able to be shortened... if anything lengthened .... So the idea is kinda like slow train fast train
15:22:05 kashyap (So the plan _did_ work :D)
15:22:29 donnyd kashyap: LOL
15:23:14 kashyap donnyd: So, yeah, moral: "punchy quotes don't cook rice [or sustain punches / win matches]"
15:23:25 donnyd So if someone wanted to ride the fast train, they would just use the minor release cycle and those who want that "LTSish" release could just use majors
15:25:34 donnyd I am still reading the thread from 2015
15:38:49 efried gibi: you still around?
15:38:58 gibi efried: yes
15:39:35 efried gibi: would you mind injecting some more description into the commit message and test comments/docstring for https://review.opendev.org/#/c/684545/ ?
15:39:54 efried As it is I have to go read the bug report to understand what's going on.
15:40:32 gibi efried: you mean describe the bug a bit more in the commit message and the docstring?
15:41:05 efried Yeah. Actually the commit message is probably fine; I just misread it. But in the test case, an up-front docstring/comment describing what we're testing for would be nice.

Earlier   Later