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
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
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
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
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
> >>
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
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
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
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
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
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
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
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
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
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
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
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?
*
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
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
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
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
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
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
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
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
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
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
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.
>
>
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
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
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
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
- 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
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
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
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
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
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
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?
>
>
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
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
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
> 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
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,
- 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
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
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,
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
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
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
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
> 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
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_
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
>>
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
] 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
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...
> >
>
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
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
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
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
>
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
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
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
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 - 100 of 138 matches
Mail list logo