Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 4:17 PM, Thierry Carrez wrote: > Hi everyone, > > Over the past year, it has become pretty obvious to me that our > self-imposed rhythm no longer matches our natural pace. It feels like we > are always running elections, feature freeze is always just

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/21/2017 07:27 PM, Matt Riedemann wrote: On 12/21/2017 4:37 PM, Joshua Harlow wrote: My 3 cents are that this isn't something that u get asked to put in from operators, it's something that is built in from the start. Just look at other workflow systems (which is really what

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/21/2017 4:37 PM, Joshua Harlow wrote: My 3 cents are that this isn't something that u get asked to put in from operators, it's something that is built in from the start. Just look at other workflow systems (which is really what nova/cinder/neutron... are); they don't try to add this

Re: [openstack-dev] [all] Switching to longer development cycles

My 3 cents are that this isn't something that u get asked to put in from operators, it's something that is built in from the start. Just look at other workflow systems (which is really what nova/cinder/neutron... are); they don't try to add this functionality in later (or they shouldn't at

Re: [openstack-dev] [all] Switching to longer development cycles

On 21/12/17 12:57, McLellan, Steven wrote: > > On 12/20/17, 5:29 PM, "Matt Riedemann" wrote: > > On 12/20/2017 3:21 PM, Matt Riedemann wrote: > > On 12/20/2017 9:30 AM, Zane Bitter wrote: > >> To answer the question from your other mail about user-space > >>

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/20/17, 5:29 PM, "Matt Riedemann" wrote: On 12/20/2017 3:21 PM, Matt Riedemann wrote: > On 12/20/2017 9:30 AM, Zane Bitter wrote: >> To answer the question from your other mail about user-space >> notifications: >> >>> We (Zaqar team) have

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/20/2017 3:21 PM, Matt Riedemann wrote: On 12/20/2017 9:30 AM, Zane Bitter wrote: To answer the question from your other mail about user-space notifications: We (Zaqar team) have been asked many times about this area but without a support from more services, it's hard. I know Heat has

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/20/2017 9:30 AM, Zane Bitter wrote: To answer the question from your other mail about user-space notifications: We (Zaqar team) have been asked many times about this area but without a support from more services, it's hard. I know Heat has some best practice using Zaqar, is it possible

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/19/2017 9:15 PM, Fei Long Wang wrote: That's one of the changes we (at least me and Rob Cresswell) would like to improve in Horizon. The idea is services (Nova, Cinder, Nutron, etc) putting notifications into Zaqar queue and then Horizon can easily get the resources status instead of doing

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/19/2017 2:29 PM, Joshua Harlow wrote: * Clear workflow state (and transition) 'machine' that is followed in code and can be used by operators/others such as UI developers to get a view on what nova is or is not doing (may fit under the broad topic of observability?) Take for example

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/19/2017 1:20 PM, Zane Bitter wrote: Getting off-topic, but since you walked in to this one ;) I sure did. On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and apparently is a priority to everyone else in the OpenStack ecosystem

Re: [openstack-dev] [all] Switching to longer development cycles

Zane Bitter wrote: On 19/12/17 22:15, Fei Long Wang wrote: On 20/12/17 09:29, Joshua Harlow wrote: Zane Bitter wrote: Getting off-topic, but since you walked in to this one ;) On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and

Re: [openstack-dev] [all] Switching to longer development cycles

On 19/12/17 22:15, Fei Long Wang wrote: On 20/12/17 09:29, Joshua Harlow wrote: Zane Bitter wrote: Getting off-topic, but since you walked in to this one ;) On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and apparently is a priority

Re: [openstack-dev] [all] Switching to longer development cycles

On 20/12/17 09:29, Joshua Harlow wrote: > Zane Bitter wrote: >> Getting off-topic, but since you walked in to this one ;) >> >> On 14/12/17 21:43, Matt Riedemann wrote: >>> What are the real problems that the Nova team is not working on and >>> apparently is a priority to everyone else in the

Re: [openstack-dev] [all] Switching to longer development cycles

On 20/12/17 07:07, Zane Bitter wrote: > On 13/12/17 11:17, Thierry Carrez wrote: >> So... What do you think ? > > Some points against that I haven't seen mentioned much yet: > > * Following our standard deprecation policy, it would take up to 3 > years to remove anything. For perspective, 3

Re: [openstack-dev] [all] Switching to longer development cycles

On 20/12/17 08:20, Zane Bitter wrote: > Getting off-topic, but since you walked in to this one ;) > > On 14/12/17 21:43, Matt Riedemann wrote: >> What are the real problems that the Nova team is not working on and >> apparently is a priority to everyone else in the OpenStack ecosystem >> but we

Re: [openstack-dev] [all] Switching to longer development cycles

Zane Bitter wrote: Getting off-topic, but since you walked in to this one ;) On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and apparently is a priority to everyone else in the OpenStack ecosystem but we are somehow oblivious? *

Re: [openstack-dev] [all] Switching to longer development cycles

Getting off-topic, but since you walked in to this one ;) On 14/12/17 21:43, Matt Riedemann wrote: What are the real problems that the Nova team is not working on and apparently is a priority to everyone else in the OpenStack ecosystem but we are somehow oblivious? * Providing a secure

Re: [openstack-dev] [all] Switching to longer development cycles

On 13/12/17 11:17, Thierry Carrez wrote: So... What do you think ? Some points against that I haven't seen mentioned much yet: * Following our standard deprecation policy, it would take up to 3 years to remove anything. For perspective, 3 years ago we had just shipped Juno. (I feel old

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 11:17 AM, Thierry Carrez wrote: Hi everyone, Over the past year, it has become pretty obvious to me that our self-imposed rhythm no longer matches our natural pace. It feels like we are always running elections, feature freeze is always just around the corner, we lose too much

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017, 4:20 PM Thierry Carrez wrote: > Ed Leafe wrote: > > On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > > > >> There is a risk that deployment to production is delayed, and therefore > feedback is delayed and the wait for the ‘initial

Re: [openstack-dev] [all] Switching to longer development cycles

On Sat, Dec 16, 2017 at 08:16:13AM -0600, Matt Riedemann wrote: > On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote: Hi Matt, First, thanks for the detailed reply with specific examples. [...] > > But one pontential question that comes to mind from that old thread is > > how is this new proposal

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Thomas Goirand's message of 2017-12-15 16:15:04 +0100: > On 12/14/2017 12:44 AM, Clint Byrum wrote: > > We can take stock of the intermediate releases over the last year, and make > > sure they all work together once a year. Chris Jones mentioned that we > > should > > give users

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote: Thinking a bit more, the above reminds of this[*] by DanPB a couple of years ago, where Dan's 'Modest Proposal' was: "switch to a development cycle that is exactly 2 months". But one pontential question that comes to mind from that old thread is

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14, 2017 at 12:02:13PM +0100, Kashyap Chamarthy wrote: > On Wed, Dec 13, 2017 at 05:17:26PM +0100, Thierry Carrez wrote: [...] > > What it means: > > > > - We'd only do one *coordinated* release of the OpenStack components > > per year, and maintain one stable branch per year

Re: [openstack-dev] [all] Switching to longer development cycles

On Fri, Dec 15, 2017 at 10:11:24AM +0800, Zhenyu Zheng wrote: > On Thu, Dec 14, 2017 at 7:02 PM, Kashyap Chamarthy > wrote: [...] > > For a relatively mature (~7 years; and ~5 years if we count from the > > time governance changed to OpenStack Foudation) project, one

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/15/2017 05:52 PM, Matt Riedemann wrote: > On 12/15/2017 9:15 AM, Thomas Goirand wrote: >> Not only that. Everyone is lagging a few release behind, and currently, >> upstream OpenStack don't care backporting to older releases. > > Can you clarify this please? The nova team is definitely

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14, 2017 at 7:07 AM, Dan Smith wrote: > > > Agreed. The first reaction I had to this proposal was pretty much what > you state here: that now the 20% person has a 365-day window in which > they have to keep their head in the game, instead of a 180-day one. > >

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/15/2017 9:15 AM, Thomas Goirand wrote: Not only that. Everyone is lagging a few release behind, and currently, upstream OpenStack don't care backporting to older releases. Can you clarify this please? The nova team is definitely backporting fixes to pike, ocata and newton. Newton isn't

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 12:44 AM, Clint Byrum wrote: > We can take stock of the intermediate releases over the last year, and make > sure they all work together once a year. Chris Jones mentioned that we should > give users time between milestones and release. I suggest we release an > intermediary and

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/15/2017 11:00 AM, Luigi Toscano wrote: - Original Message - On 12/14/2017 9:38 AM, Luigi Toscano wrote: And the QE in me says that there are enough moving parts around for the integration testing (because CD yes, but the resources are limited) that a longer cycle with a longer

Re: [openstack-dev] [all] Switching to longer development cycles

Adrian Turjak wrote: > I worry that moving to a yearly release is actually going to make things > worse for deployers and there will be less encouragement for them to be > on more up to date and bug fixed code. Not to mention, no one will trust > or use the intermediary releases unless they are

Re: [openstack-dev] [all] Switching to longer development cycles

- Original Message - > On 12/14/2017 9:38 AM, Luigi Toscano wrote: > > And the QE in me says that there are enough moving parts around for the > > integration testing (because CD yes, but the resources are limited) that a > > longer cycle with a longer time between freeze and release is

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 11:12 AM, Dean Troyer wrote: On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann wrote: What would our world look like if we treated inter-service dependencies like we do service-to-library dependencies and only integration test released components, rather than

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 3:27 PM, Adrian Turjak wrote: I worry that moving to a yearly release is actually going to make things worse for deployers and there will be less encouragement for them to be on more up to date and bug fixed code. Not to mention, no one will trust or use the intermediary releases

Re: [openstack-dev] [all] Switching to longer development cycles

The contributors in APAC are growing and wish to be more involved in OpenStack, it will be really hard for us to join informal meetups( VISA Invitation letters, company support etc.) So I really hope the current official technical gathering remains, so that we can be more involved with the

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14, 2017 at 7:02 PM, Kashyap Chamarthy wrote: > [..] > > For a relatively mature (~7 years; and ~5 years if we count from the > time governance changed to OpenStack Foudation) project, one official > contributor gathering per year sounds fine. And for those that

Re: [openstack-dev] [all] Switching to longer development cycles

I worry that moving to a yearly release is actually going to make things worse for deployers and there will be less encouragement for them to be on more up to date and bug fixed code. Not to mention, no one will trust or use the intermediary releases unless they are coordinated and tested much

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 03:16 PM, Ed Leafe wrote: > On Dec 14, 2017, at 3:01 AM, Thomas Goirand wrote: >> >> As a package maintainer who no longer can follow the high pace, I very >> much support this change. > > So you’re saying that you would be ignoring any intermediate releases? > >

Re: [openstack-dev] [all] Switching to longer development cycles

On 14 December 2017 at 07:09, Nick Barcet wrote: > Hello Thierry, > > Really appreciate the effort you are putting to find creative ways to help > new contributors join our project. However, based on my experience, it > seems that: > - the longer the delay between the

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 9:38 AM, Luigi Toscano wrote: And the QE in me says that there are enough moving parts around for the integration testing (because CD yes, but the resources are limited) that a longer cycle with a longer time between freeze and release is better to refine the testing part. The

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann wrote: > What would our world look like if we treated inter-service dependencies like > we do service-to-library dependencies and only integration test released > components, rather than installing everything from source by

Re: [openstack-dev] [all] Switching to longer development cycles

> On Dec 13, 2017, at 6:44 PM, Clint Byrum wrote: > > Excerpts from Thierry Carrez's message of 2017-12-13 17:17:26 +0100: >> Hi everyone, >> >> Over the past year, it has become pretty obvious to me that our >> self-imposed rhythm no longer matches our natural pace. It feels

Re: [openstack-dev] [all] Switching to longer development cycles

On 2017-12-14 08:15:51 -0700 (-0700), Clint Byrum wrote: [...] > What if we did a community goal to get upgrade testing solidified, > and have it test upgrading each project from _three_ stable releases > prior. So, if we did this for Rocky, we'd make sure you could upgrade > to Rocky from Queens,

Re: [openstack-dev] [all] Switching to longer development cycles

- Original Message - > On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > > > There is a risk that deployment to production is delayed, and therefore > > feedback is delayed and the wait for the ‘initial bug fixes before we > > deploy to prod’ gets longer. > > There is

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 9:11 AM, Thierry Carrez wrote: We lose development time to activities directly linked to our cycle: like election, release, PTG preparation, participation to Forum(s). PTLs have reported not being able to achieve much before reaching the end of a cycle and having to stand for

Re: [openstack-dev] [all] Switching to longer development cycles

Ed Leafe writes: > I think you're missing the reality that intermediate releases have > about zero uptake in the real world. We have had milestone releases of > Nova for years, but I challenge you to find me one non-trivial > deployment that uses one of them. To my knowledge,

Re: [openstack-dev] [all] Switching to longer development cycles

I feel like the thing not stated is that what we really don't like is that our users are falling behind. Sure, pressure in release time is definitely real. Multiple PTG's and forums feels like people are missing out. But what's really awful is that some of our users are stuck down in the bottom of

Re: [openstack-dev] [all] Switching to longer development cycles

TL;DR: +1 for 1-year release, without reducing face-to-face meetings. On Wed, Dec 13, 2017 at 6:35 PM Matt Riedemann wrote: > > Same question as above about just doing CD then. Why not getting rid of stable branches and releases altogether then? Honestly, I'm a big fan

Re: [openstack-dev] [all] Switching to longer development cycles

Chris Dent wrote: > On Thu, 14 Dec 2017, Julien Danjou wrote: > >> However, has anyone tried to understand the reasons why it is hard to >> impossible to do anything useful in a cycle, other than "it is too >> short"? > > This gets to the root my concern with this proposal and this thread. > I

Re: [openstack-dev] [all] Switching to longer development cycles

Hello Thierry, Really appreciate the effort you are putting to find creative ways to help new contributors join our project. However, based on my experience, it seems that: - the longer the delay between the releases, the harder they are to deliver - the main problem newcomers may have today, is

Re: [openstack-dev] [all] Switching to longer development cycles

> In my experience, the longer a patch (or worse, patch series) sits > around, the staler it gets. Others are merging changes, so the > long-lived patch series has to be constantly rebased. This is definitely true. > The 20% developer would be spending a greater proportion of her time > figuring

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 12:36 AM, Clint Byrum wrote: This isn't really fair to the users. They're running what we tell them to run. They're also running what we try to test together, which is all the same versions of the same components at integrated release time. While I do think most users_should_

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 7:07 AM, Thierry Carrez wrote: It takes time to get a feature merged (or any significant work done) in OpenStack. It takes time to get reviews, we need to be careful about not breaking all our users, etc. If you are a 20% time person, it's just impossible to get something

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, 14 Dec 2017, Julien Danjou wrote: However, has anyone tried to understand the reasons why it is hard to impossible to do anything useful in a cycle, other than "it is too short"? This gets to the root my concern with this proposal and this thread. I think the idea deserves plenty of

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 22:55:43 -0600: > On Dec 13, 2017, at 4:38 PM, German Eichberger > wrote: > > > It looks like the implicit expectation is that devs also need to attend the > > Forums at the summit in addition to the PTG. The

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 14, 2017, at 7:07 AM, Thierry Carrez wrote: > > It takes time to get a feature merged (or any significant work done) in > OpenStack. It takes time to get reviews, we need to be careful about not > breaking all our users, etc. If you are a 20% time person, it's just

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 14, 2017, at 3:01 AM, Thomas Goirand wrote: > > As a package maintainer who no longer can follow the high pace, I very > much support this change. So you’re saying that you would be ignoring any intermediate releases? -- Ed Leafe

Re: [openstack-dev] [all] Switching to longer development cycles

On 2017-12-14 12:15:08 +0100 (+0100), Dmitry Tantsur wrote: [...] > loop operators into PTGs more. If by "operators" you mean people who run OpenStack, then yes while many of our developers are also operators it definitely makes sense to have increasing amounts of overlap with operators

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14 2017, Thierry Carrez wrote: > It takes time to get a feature merged (or any significant work done) in > OpenStack. It takes time to get reviews, we need to be careful about not > breaking all our users, etc. If you are a 20% time person, it's just > impossible to get something

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 14, 2017, at 12:55 AM, Clint Byrum wrote: >> The rest of OpenStack is what Nova originally was. It was split into many >> different project because of the sheer complexity of the tasks it had to >> perform. But splitting it up required that we occasionally have to make

Re: [openstack-dev] [all] Switching to longer development cycles

Julien Danjou wrote: > On Thu, Dec 14 2017, Thierry Carrez wrote: > >> - People who would like to get more involved (and become core >> developers) but can't keep up with what's happening in their project or >> reach the review activity necessary to become core developers. A number >> of projects

Re: [openstack-dev] [all] Switching to longer development cycles

I noticed some OpenStack distro vendors in China(not all the vendors) like the idea to have one release per year. There are couple of different reason: 1. It takes about 3 to 6 months to productize the release. But customers always expect the vendors to productize every single release, which cost

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14, 2017 at 10:09 AM, Thierry Carrez wrote: > Matt Riedemann wrote: > > On 12/13/2017 4:15 PM, Thierry Carrez wrote: > >> Based on several discussions I had with developers working part-time on > >> OpenStack at various events lately, it sounded like slowing

Re: [openstack-dev] [all] Switching to longer development cycles

I think this is in-line with my earlier points. Projects started later, with clear API definitions, are easier to run on whatever version you need. They don't dig in under the hood the way Neutron/Nova/Cinder do because of their shared history. It also helps that they don't require a bunch of

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/14/2017 05:55 AM, Ed Leafe wrote: On Dec 13, 2017, at 4:38 PM, German Eichberger wrote: It looks like the implicit expectation is that devs also need to attend the Forums at the summit in addition to the PTG. The Forums, though important, hardly made

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 11:20 PM, Thierry Carrez wrote: Ed Leafe wrote: On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: There is a risk that deployment to production is delayed, and therefore feedback is delayed and the wait for the ‘initial bug fixes before we deploy to prod’ gets

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 05:17:26PM +0100, Thierry Carrez wrote: > Hi everyone, Hey Thierry, > Over the past year, it has become pretty obvious to me that our > self-imposed rhythm no longer matches our natural pace. It feels like we > are always running elections, feature freeze is always just

Re: [openstack-dev] [all] Switching to longer development cycles

On 14 Dec 2017, 17:04 +0700, wrote: > > Can you detail more how having a longer cycle will make people that > spends 20% of their time on OpenStack "catch up" with the people that > spends 80% of their time on OpenStack? > > I understand the problem but I don't see how the proposed solution >

Re: [openstack-dev] [all] Switching to longer development cycles

iling List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: Wednesday, December 13, 2017 at 10:15 AM > > > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14 2017, Thierry Carrez wrote: > - People who would like to get more involved (and become core > developers) but can't keep up with what's happening in their project or > reach the review activity necessary to become core developers. A number > of projects are struggling to recruit

Re: [openstack-dev] [all] Switching to longer development cycles

Matt Riedemann wrote: > On 12/13/2017 4:15 PM, Thierry Carrez wrote: >> Based on several discussions I had with developers working part-time on >> OpenStack at various events lately, it sounded like slowing down our >> pace could be helpful to them and generally reduce stress in OpenStack >>

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 05:17 PM, Thierry Carrez wrote: > So... What do you think ? As a package maintainer who no longer can follow the high pace, I very much support this change. Cheers, Thomas Goirand (zigo) __ OpenStack

Re: [openstack-dev] [all] Switching to longer development cycles

David Moreau Simard wrote: > This can go down a few different ways, I guess we can: > 1) Extend the support of a stable release by a full year >     This keeps the two rolling stable releases plus the one in development. >     Not quite LTS, but you know, it's still 2 years of support instead of

Re: [openstack-dev] [all] Switching to longer development cycles

Thanks a lot to open this topic. I want to open this topic like this some times, but i thought, may be myself is too sensitive? To me, i found as Openstack mature, the developer is less valuable. The devs can install it then teach user to use it, then ok the deal is done. The Openstack in many

Re: [openstack-dev] [all] Switching to longer development cycles

The former - we're running Cells so only have a single region currently (except for Swift where we have multiple proxy endpoints around the country, all backed by a global cluster, but they have to be different regions to put them all in the service catalog). See

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Blair Bethwaite's message of 2017-12-14 17:44:53 +1100: > On 14 December 2017 at 17:36, Clint Byrum wrote: > > The batch size for "upgrade the whole cloud" is too big. Let's help our > > users advance components one at a time, and then we won't have to worry > > so

Re: [openstack-dev] [all] Switching to longer development cycles

Maybe not exactly on the topic but I’d like to express some more thoughts on OpenStack development rhythm being too harsh for newcomers and part time developers. Although I partially agree with the initial Thierry’s point I think the key thing here itself is that they are part time developers.

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 23:02:11 -0600: > On Dec 13, 2017, at 5:44 PM, Clint Byrum wrote: > > > One thing I've always admired about Swift was how immune to the cadence > > Swift > > appears to be. > > As I've pointed out before [0], Swift is a whole

Re: [openstack-dev] [all] Switching to longer development cycles

On 14 December 2017 at 17:36, Clint Byrum wrote: > The batch size for "upgrade the whole cloud" is too big. Let's help our > users advance components one at a time, and then we won't have to worry > so much about doing the whole integrated release dance so often. Is there any

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 22:51:19 -0600: > On Dec 13, 2017, at 4:31 PM, Doug Hellmann wrote: > > > You're missing the key point that coupled with the change in the > > overall development cycle schedule we would be encouraging projects > > to release

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 5:44 PM, Clint Byrum wrote: > One thing I've always admired about Swift was how immune to the cadence Swift > appears to be. As I've pointed out before [0], Swift is a whole 'nother thing. It does not have API interdependencies with anything else in

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 4:38 PM, German Eichberger wrote: > It looks like the implicit expectation is that devs also need to attend the > Forums at the summit in addition to the PTG. The Forums, though important, > hardly made it worthwhile for me to attend the

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 4:31 PM, Doug Hellmann wrote: > You're missing the key point that coupled with the change in the > overall development cycle schedule we would be encouraging projects > to release more often. I'd personally rather do away with milestones > altogether

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Thierry Carrez's message of 2017-12-13 17:17:26 +0100: > Hi everyone, > > Over the past year, it has become pretty obvious to me that our > self-imposed rhythm no longer matches our natural pace. It feels like we > are always running elections, feature freeze is always just around

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 9:13 PM, Matt Riedemann wrote: > On 12/13/2017 4:15 PM, Thierry Carrez wrote: > >> Based on several discussions I had with developers working part-time on >> OpenStack at various events lately, it sounded like slowing down our >> pace could be helpful

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 4:15 PM, Thierry Carrez wrote: Based on several discussions I had with developers working part-time on OpenStack at various events lately, it sounded like slowing down our pace could be helpful to them and generally reduce stress in OpenStack development. I know people who can

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Arkady.Kanevsky's message of 2017-12-14 02:44:24 +: > How about add to our biannual questionnaire how often customer upgrade their > openstack environment? There is quite a bit of information about deployments in the latest user survey [1], starting on page 24. Page 29 shows

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 11:17 AM, Thierry Carrez wrote: > - It doesn't mean that teams can only meet in-person once a year. > Summits would still provide a venue for team members to have an > in-person meeting. I also expect a revival of the team-organized > midcycles to

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 4:20 PM, Thierry Carrez wrote: Is the "rush" at the end of the cycle still a thing those days ? From a release management perspective it felt like the pressure was reduced in recent cycles, with less and less FFEs. But that may be that PTLs have gotten better at denying them, not

Re: [openstack-dev] [all] Switching to longer development cycles

] Switching to longer development cycles Ed Leafe wrote: > On Dec 13, 2017, at 12:13 PM, Tim Bell <tim.b...@cern.ch> wrote: > >> There is a risk that deployment to production is delayed, and therefore >> feedback is delayed and the wait for the ‘initial bug fixes before we

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Chris Jones's message of 2017-12-13 19:25:03 +: > Hey > > On 13 December 2017 at 17:31, Thierry Carrez wrote: > > > See attached for the PDF strawman the release team came up with when > > considering how that change would roll out in practice... > > >

Re: [openstack-dev] [all] Switching to longer development cycles

rg> Date: Wednesday, December 13, 2017 at 10:15 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [all] Switching to longer development cycles The forums would seem to provide a good opportunity

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 16:07:50 -0600: > On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > > > There is a risk that deployment to production is delayed, and therefore > > feedback is delayed and the wait for the ‘initial bug fixes before we > > deploy to

Re: [openstack-dev] [all] Switching to longer development cycles

Ed Leafe wrote: > On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > >> There is a risk that deployment to production is delayed, and therefore >> feedback is delayed and the wait for the ‘initial bug fixes before we deploy >> to prod’ gets longer. > > There is always a rush at

Re: [openstack-dev] [all] Switching to longer development cycles

Doug Hellmann wrote: > That said, I'm more interested in settling the question of whether > changing the development cycle helps development teams in any way > before we consider other effects. Because if it doesn't do any good > then there's no reason to solve problems we won't have, and if we >

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > There is a risk that deployment to production is delayed, and therefore > feedback is delayed and the wait for the ‘initial bug fixes before we deploy > to prod’ gets longer. There is always a rush at the Feature Freeze point

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Thierry Carrez's message of 2017-12-13 22:26:49 +0100: > Doug Hellmann wrote: > > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: > >> Do we continue to support the previous two releases as stable branches? > >> Doesn't that mean we double the amount of time we

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 03:16:33PM -0500, Doug Hellmann wrote: > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: > > Do we continue to support the previous two releases as stable branches? > > Doesn't that mean we double the amount of time we need to keep older CI > > setups

Re: [openstack-dev] [all] Switching to longer development cycles

Doug Hellmann wrote: > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: >> Do we continue to support the previous two releases as stable branches? >> Doesn't that mean we double the amount of time we need to keep older CI >> setups around? Isn't that already a pain point for the

  1   2   >