subject:"\[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 some best
practice using Zaqar, is it possible to "copy" it to 
Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly 
clear that under no circumstances would they ever accept any code like 
this in Nova. Hence it's on this list.


Again, this is news to me. Why isn't this proposed as a community-wide 
goal for Rocky?


And if it would be dead easy, why aren't we trying to get part time or 
new contributors to work on this, like OSIC was for awhile around the 
time of the Austin summit?




Now I know.

http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-20.log.html#t2017-12-20T21:46:11

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 to "copy" it to Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly 
clear that under no circumstances would they ever accept any code like 
this in Nova. Hence it's on this list.


Again, this is news to me. Why isn't this proposed as a community-wide 
goal for Rocky?


And if it would be dead easy, why aren't we trying to get part time or 
new contributors to work on this, like OSIC was for awhile around the 
time of the Austin summit?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 stupid polling. And it could be
easily doing the thing shown on above link.


Why can't you listen on the existing nova notifications over RPC 
(versioned notifications preferably)?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 http://flower.readthedocs.io/en/latest/screenshots.html 
and ask yourself why nova-compute (or nova-conductor or 
nova-scheduler...) doesn't have an equivalent kind of 'viewer' (and no 
it doesn't need to be flower, that's just an example...)


OK...first I've heard of this too. Is this something that the majority 
of people deploying, operating and/or using Nova are asking for as a 
priority?


Also, this doesn't just seem like a nova thing - this smells like a 
community-wide goal.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 
but we are somehow oblivious?


* Providing a secure channel to get credentials to guests so that 
applications running on them can authenticate to OpenStack APIs.


OK yeah, forgot about that one. I remember forum sessions on this in 
Boston and there were some TODOs from that, but I can't say I remember 
off the top of my head what the TODOs were and who the owners were, but 
I thought I remember Monty signing up for something. I might have just 
totally thrown him under the bus though.




* Providing reliable, user-space notifications of events that may 
require application or application-operator intervention (e.g. VM 
reboot, hypervisor died, ).




This one is news to me.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-20 Thread Joshua Harlow


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
apparently is a priority to everyone else in the OpenStack ecosystem
but we are somehow oblivious?


* Providing a secure channel to get credentials to guests so that
applications running on them can authenticate to OpenStack APIs.

* Providing reliable, user-space notifications of events that may
require application or application-operator intervention (e.g. VM
reboot, hypervisor died, ).


I'll add on.

* 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
http://flower.readthedocs.io/en/latest/screenshots.html and ask
yourself why nova-compute (or nova-conductor or nova-scheduler...)
doesn't have an equivalent kind of 'viewer' (and no it doesn't need to
be flower, that's just an example...)



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 stupid polling. And it could be
easily doing the thing shown on above link.


What you're talking about is really an expansion of my second item
above. What Josh means is using the taskflow library to co-ordinate all
of the steps involved internally to Nova to boot an instance
(scheduling, attaching volumes & ports, actually creating the VM, ) -
it's not really a user-space thing.


I'm fine also with not using taskflow, just use something (vs nothing) ;)



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 to "copy" it to Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly
clear that under no circumstances would they ever accept any code like
this in Nova. Hence it's on this list.

cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-20 Thread Zane Bitter


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 to everyone else in the OpenStack ecosystem
but we are somehow oblivious?


* Providing a secure channel to get credentials to guests so that
applications running on them can authenticate to OpenStack APIs.

* Providing reliable, user-space notifications of events that may
require application or application-operator intervention (e.g. VM
reboot, hypervisor died, ).


I'll add on.

* 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
http://flower.readthedocs.io/en/latest/screenshots.html and ask
yourself why nova-compute (or nova-conductor or nova-scheduler...)
doesn't have an equivalent kind of 'viewer' (and no it doesn't need to
be flower, that's just an example...)



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 stupid polling. And it could be
easily doing the thing shown on above link.


What you're talking about is really an expansion of my second item 
above. What Josh means is using the taskflow library to co-ordinate all 
of the steps involved internally to Nova to boot an instance 
(scheduling, attaching volumes & ports, actually creating the VM, ) - 
it's not really a user-space thing.


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 to "copy" it to Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly 
clear that under no circumstances would they ever accept any code like 
this in Nova. Hence it's on this list.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Fei Long Wang



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 OpenStack ecosystem
>>> but we are somehow oblivious?
>>
>> * Providing a secure channel to get credentials to guests so that
>> applications running on them can authenticate to OpenStack APIs.
>>
>> * Providing reliable, user-space notifications of events that may
>> require application or application-operator intervention (e.g. VM
>> reboot, hypervisor died, ).
>
> I'll add on.
>
> * 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
> http://flower.readthedocs.io/en/latest/screenshots.html and ask
> yourself why nova-compute (or nova-conductor or nova-scheduler...)
> doesn't have an equivalent kind of 'viewer' (and no it doesn't need to
> be flower, that's just an example...)
>

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 stupid polling. And it could be
easily doing the thing shown on above link.

>>
>> - ZB
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Fei Long Wang



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 years ago we had just
> shipped Juno. (I feel old now.)
>
> * Other large, complex software distributions have moved to 6-month or
> shorter development cycles (e.g. Ubuntu, Fedora, Chromium, Linux,
> Firefox), with apparent success. What do we think is different about
> the context in which we work that makes it a good idea to go in the
> other direction?
>
> * Upgrading OpenStack is painful for our users. Modern software
> development theory holds that you make painful things less painful by
> doing them *more* often, in smaller bites. (And preferably make the
> developers suffer some of the pain, so they're motivated to reduce
> it.) Less frequent upgrades with bigger changes is likely to provoke
> even more of our users to remain on old releases indefinitely.
>
> * It's true that OpenStack is mature in the sense that the things it
> does are pretty stable. It's not true in the sense of it being close
> to fulfilling our mission, of implementing a full-featured cloud.
> (e.g. my pet bug-bear: applications can't use it unless they have
> economies of scale, are prepared to implement a bunch of stuff
> themselves, and are extremely motivated to use OpenStack over
> alternatives that are designed with application support in mind... so
> basically just infra.) We absolutely need to keep up a fast pace of
> innovation in order not to become irrelevant.
>

+100

> * Natural complements to OpenStack like Kubernetes also have rapid
> release cycles. If we're unable to respond rapidly to changes in them
> (by adjusting our integration points in a timely fashion) then they're
> going to be more inclined to put effort into working around OpenStack
> than into working together. (The fact that said integration points
> largely don't exist at the moment is also an example of the previous
> point.)

Very good point.

>
> * As someone who will probably volunteer as a PTL again at some point,
> the prospect of having to sign up for an entire year is a major
> disincentive to do so.
>
>
> I'm all for encouraging companies who are using OpenStack to
> contribute e.g. 20% of a developer to helping out upstream. I'm not at
> all convinced that regular releases are an obstacle to that - by the
> 'pace' of development I suspect they mean the constant code churn
> resulting in never-ending rebases of outstanding patches that they
> struggle to get reviews on (often, it must be said, because they are
> GIANT), and not the release cadence. So count me as -1 on this change.
>
> cheers,
> Zane.
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Fei Long Wang



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 are somehow oblivious?
>
> * Providing a secure channel to get credentials to guests so that
> applications running on them can authenticate to OpenStack APIs.
>

I'm trying to do that in Trove with Zaqar, if there is any interest,
please jump in #openstack-zaqar and let's have a talk.

> * Providing reliable, user-space notifications of events that may
> require application or application-operator intervention (e.g. VM
> reboot, hypervisor died, ).

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 to "copy" it to Nova/Cinder/Neutron?

>
> - ZB
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Joshua Harlow


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?


* Providing a secure channel to get credentials to guests so that
applications running on them can authenticate to OpenStack APIs.

* Providing reliable, user-space notifications of events that may
require application or application-operator intervention (e.g. VM
reboot, hypervisor died, ).


I'll add on.

* 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 http://flower.readthedocs.io/en/latest/screenshots.html 
and ask yourself why nova-compute (or nova-conductor or 
nova-scheduler...) doesn't have an equivalent kind of 'viewer' (and no 
it doesn't need to be flower, that's just an example...)




- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Zane Bitter


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 channel to get credentials to guests so that 
applications running on them can authenticate to OpenStack APIs.


* Providing reliable, user-space notifications of events that may 
require application or application-operator intervention (e.g. VM 
reboot, hypervisor died, ).


- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Zane Bitter


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 now.)


* Other large, complex software distributions have moved to 6-month or 
shorter development cycles (e.g. Ubuntu, Fedora, Chromium, Linux, 
Firefox), with apparent success. What do we think is different about the 
context in which we work that makes it a good idea to go in the other 
direction?


* Upgrading OpenStack is painful for our users. Modern software 
development theory holds that you make painful things less painful by 
doing them *more* often, in smaller bites. (And preferably make the 
developers suffer some of the pain, so they're motivated to reduce it.) 
Less frequent upgrades with bigger changes is likely to provoke even 
more of our users to remain on old releases indefinitely.


* It's true that OpenStack is mature in the sense that the things it 
does are pretty stable. It's not true in the sense of it being close to 
fulfilling our mission, of implementing a full-featured cloud. (e.g. my 
pet bug-bear: applications can't use it unless they have economies of 
scale, are prepared to implement a bunch of stuff themselves, and are 
extremely motivated to use OpenStack over alternatives that are designed 
with application support in mind... so basically just infra.) We 
absolutely need to keep up a fast pace of innovation in order not to 
become irrelevant.


* Natural complements to OpenStack like Kubernetes also have rapid 
release cycles. If we're unable to respond rapidly to changes in them 
(by adjusting our integration points in a timely fashion) then they're 
going to be more inclined to put effort into working around OpenStack 
than into working together. (The fact that said integration points 
largely don't exist at the moment is also an example of the previous point.)


* As someone who will probably volunteer as a PTL again at some point, 
the prospect of having to sign up for an entire year is a major 
disincentive to do so.



I'm all for encouraging companies who are using OpenStack to contribute 
e.g. 20% of a developer to helping out upstream. I'm not at all 
convinced that regular releases are an obstacle to that - by the 'pace' 
of development I suspect they mean the constant code churn resulting in 
never-ending rebases of outstanding patches that they struggle to get 
reviews on (often, it must be said, because they are GIANT), and not the 
release cadence. So count me as -1 on this change.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-19 Thread Ben Swartzlander


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 time to events, and generally the impression
that there is less time to get things done. Milestones in the
development cycles are mostly useless now as they fly past us too fast.
A lot of other people reported that same feeling.

As our various components mature, we have less quick-paced feature
development going on. As more and more people adopt OpenStack, we are
more careful about not breaking them, which takes additional time. The
end result is that getting anything done in OpenStack takes more time
than it used to, but we have kept our cycle rhythm mostly the same.

Our development pace was also designed for fast development in a time
where most contributors were full time on OpenStack. But fewer and fewer
people have 100% of their time to dedicate to OpenStack upstream
development: a lot of us now have composite jobs or have to participate
in multiple communities. This is a good thing, and it will only
accelerate as more and more OpenStack development becomes fueled
directly by OpenStack operators and users.

In another thread, John Dickinson suggested that we move to one-year
development cycles, and I've been thinking a lot about it. I now think
it is actually the right way to reconcile our self-imposed rhythm with
the current pace of development, and I would like us to consider
switching to year-long development cycles for coordinated releases as
soon as possible.

What it means:

- We'd only do one *coordinated* release of the OpenStack components per
year, and maintain one stable branch per year
- We'd elect PTLs for one year instead of every 6 months
- We'd only have one set of community goals per year
- We'd have only one PTG with all teams each year

What it does _not_ mean:

- It doesn't mean we'd release components less early or less often. Any
project that is in feature development or wants to ship changes more
often is encouraged to use the cycle-with-intermediary release model and
release very early and very often. It just means that the minimum we'd
impose for mature components is one release per year instead of one
release every 6 months.

- It doesn't mean that we encourage slowing down and procrastination.
Each project would be able to set its own pace. We'd actually encourage
teams to set objectives for the various (now longer) milestones in the
cycle, and organize virtual sprints to get specific objectives done as a
group. Slowing down the time will likely let us do a better job at
organizing the work that is happening within a cycle.

- 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 replace the second PTG for teams that need or want to meet
more often.

- It doesn't mean less emphasis on common goals. While we'd set goals
only once per year, I hope that having one full year to complete those
will let us tackle more ambitious goals, or more of them in parallel.

- It doesn't simplify upgrades. The main issue with the pace of
upgrading is not the rhythm, it's the imposed timing. Being forced to
upgrade every year is only incrementally better than being forced to
upgrade every 6 months. The real solution there is better support for
skipping releases that don't matter to you, not longer development cycles.

- It doesn't give us LTS. The cost of maintaining branches is not really
due to the number of them we need to maintain in parallel, it is due to
the age of the oldest one. We might end up being able to support
branches for slightly longer as a result of having to maintain less of
them in parallel, but we will not support our stable branches for a
significantly longer time as a direct result of this change. The real
solution here is being discussed by the (still forming) LTS SIG and
involves having a group step up to continue to maintain some branches
past EOL.

Why one year ?

Why not switch to 9 months ? Beyond making the math a lot easier, this
has mostly to do with events organization. The Summits are already
locked for 2018/2019 with a pattern of happening in April/May and
October/November. As we want to keep the PTG event as a separate
work-focused productive event at the start of every cycle, and not have
it collide with one of those already-planned summits, going for a yearly
rhythm is the best solution.

When ?

If we switch, we could either pick February/March or August/September as
the start of cycle / yearly PTG time. From an events organization
perspective, it is a lot easier to organize a week-long event in
February/March. August is a no-go for a lot of the world. Early
September is a mess with various US and religious

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

2017-12-17 Thread Jay Bryant

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 bug fixes before we
> deploy to prod’ gets longer.
> >
> > There is always a rush at the Feature Freeze point in a cycle to get
> things in, or they will be delayed for 6 months. With the year-long cycle,
> now anything missing Feature Freeze will be delayed by a year. The long
> cycle also means that a lot more time will be spent backporting things to
> the current release, since people won’t be able to wait a whole year for
> some improvements.
> >
> > Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).
>
> Yes, I'll admit I'm struggling with that part of the proposal too. We
> could use intermediary releases but there would always be a "more
> important" release.
>
> 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 that the pressure is reduced now that
> we are past the hype peak...
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Thierry,

I feel like the rush at the end of a cycle had gotten better to some
extent. The features going into Cinder, however habe slowed and we have had
more ling running development.

I am afraid the rush might come back oud we have longer development cycles.

Jay

>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-17 Thread Kashyap Chamarthy

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 of 'one coordinated release per year' going to
> > address the following:
> > 
> >  If your spec didn't make into this year's coordiated release, then
> >  does it have to 'sit out' for one whole year?
> > 
> > The shorter release cycle argument addresses that by not coupling specs
> > to a single release -- where specs can be submitted regardless of a
> > release in question.  Meanwhile, code development of the feature can
> > happen over several cycles.  And periodically re-evaluate it in light of
> > new evidence and design discussions.
> > 
> > As it stands[2], this problem seems mitgated by moving specs across
> > releases and re-approving them (insofar as they make sense).  Maybe in
> > current times, the above specs issue is 'non-problem'.  Happy to be
> > corrected.
> 
> Each project would have to decide what works for them, which might mean one
> or two intermediate releases within the 1 year coordinated release where we
> have a freeze period for new features, and then open up again for new spec
> reviews after the intermediate release to allow new content in again. If no
> one is picking up the intermediate release, then it's just self-imposed to
> force us to (1) work toward a deadline and not let things drag on for a year
> and (2) allow in new specs more than once a year so the above problem
> doesn't happen, or is at least mitigated.

Okay, the above approach of per-project based decision to do
intermediate releases sounds reasonable.

> There are also comments elsewhere in this thread about extending the
> stability period, but again, that's per-project at this point. The proposal
> says nothing about a coordinated stability period.

Noted.  (Haven't caught up with all the responses yet.)

> In the last few cycles we've had I think 2 weeks between the global feature
> freeze and RC1, which isn't much time for stability and flushing out last
> minute bugs.
> 
> If we tried to incorporate both multiple freezes and stability periods, we
> might have something like:
> 
> * 3 months of new dev (maybe freeze specs after a month?)
> * 1 month of no new feature work, only bugs, docs, testing
> * intermediate release
> * 
> 
> That would give you a shorter dev cycle than what we do today (at least in
> nova), and do it three times in a year.
>
> The only contributor problem this solves is people have more opportunities
> to get their spec/new feature considered, at least more than once in a year.
> It does not, however, automatically make those specs/new features a priority
> to get review and help from the core team to shepherd them through the
> pipeline.

Yes, that's a good point.  'Consideration' is one thing, getting the
spec / feature to its logical conclusion is something else.

> There was some discussion about the priority issue during the TC office
> hours a few days ago, and Dan Smith has said it elsewhere in this thread.
> The chances of getting work done is proportional to the shared understanding
> and value of the thing being proposed, including risk/size/complexity etc.

Agreed, there are several complex variables here, and not everything can
be so cut-and-dried.

> Here are two concrete examples from part time contributors for nova:
> 
> 1. 
> https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/rebuild-keypair-reset.html
> 
> 2. 
> https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/scaleio-ephemeral-storage-backend.html
> 
 
[...] # Snip description of the above two examples.

> How do we solve that problem? Get someone from Dell/EMC to be full time
> active in Nova for a year or more and build the trust of the core team to
> want to review this change, and trust that the contributors will be around
> to maintain it after it's merged? That's not a realistic solution.

/me nods; I see your point.  And I agree, the above hypothetical is not
realistic.

> We could dig up the slots/runways idea where we essentially do Kanban and
> this gets queued up and the core team must get it in eventually to start new
> work, regardless of priority.

While I remember the terms "slots/runways" but forgot what the idea
entails (I'll look it up).

> I don't have an answer. There are options. The 1 year release idea doesn't
> magically solve this problem. And arguably doing 3 intermediate releases per
> year, if we did that to solve the "missed the 1 year boat" issue, would add
> stress to the core team/PTL because they are doing more context switching
> and schedule management, precisely what the 1 year release is proposing to
> ease. 

I agree that anything that adds more paperwork or aggravates context
switching is a net-negative.  Probably we should aim at

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

2017-12-16 Thread Clint Byrum

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 time between milestones and release. I suggest we release an
> > intermediary and _support it_. Let distros pick those up when they need to 
> > ship
> > new features.
> 
> I don't think this will happen.
> 
> > Let users jump ahead for a few projects when they need the bug fixes.
> 
> And that, I don't agree. New releases aren't to fix bugs, bugs should be
> fixed in stable too, otherwise you face new issues trying to get a
> bugfix. And that's why we have stable.
> 

We have stable for critical bug fixes. However, performance enhancements,
scalability improvements, API weirdness, are not backported. In general,
most of what arrives in each commit is good for most users. Bug fixes
are not all backported. If a regression happens, it happens because it
leverages a scenario we don't properly test.

> > I understand the belief that nobody will run the intermediaries.
> 
> Not only that. Everyone is lagging a few release behind, and currently,
> upstream OpenStack don't care backporting to older releases.
> 

Right but if you de-couple projects a bit, folks can upgrade the stuff that
they need to when they need to. As Matt R. says, this kinda works today. I
suggest we start testing it more and asserting that it works.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-16 Thread Matt Riedemann

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
how is this new proposal of 'one coordinated release per year' going to
address the following:

If your spec didn't make into this year's coordiated release, then
does it have to 'sit out' for one whole year?

The shorter release cycle argument addresses that by not coupling specs
to a single release -- where specs can be submitted regardless of a
release in question. Meanwhile, code development of the feature can
happen over several cycles. And periodically re-evaluate it in light of
new evidence and design discussions.

As it stands[2], this problem seems mitgated by moving specs across
releases and re-approving them (insofar as they make sense). Maybe in
current times, the above specs issue is 'non-problem'. Happy to be
corrected.

Each project would have to decide what works for them, which might mean
one or two intermediate releases within the 1 year coordinated release
where we have a freeze period for new features, and then open up again
for new spec reviews after the intermediate release to allow new content
in again. If no one is picking up the intermediate release, then it's
just self-imposed to force us to (1) work toward a deadline and not let
things drag on for a year and (2) allow in new specs more than once a
year so the above problem doesn't happen, or is at least mitigated.

There are also comments elsewhere in this thread about extending the
stability period, but again, that's per-project at this point. The
proposal says nothing about a coordinated stability period.

In the last few cycles we've had I think 2 weeks between the global
feature freeze and RC1, which isn't much time for stability and flushing
out last minute bugs.

If we tried to incorporate both multiple freezes and stability periods,
we might have something like:

* 3 months of new dev (maybe freeze specs after a month?)
* 1 month of no new feature work, only bugs, docs, testing
* intermediate release
*

That would give you a shorter dev cycle than what we do today (at least
in nova), and do it three times in a year.

The only contributor problem this solves is people have more
opportunities to get their spec/new feature considered, at least more
than once in a year. It does not, however, automatically make those
specs/new features a priority to get review and help from the core team
to shepherd them through the pipeline.

There was some discussion about the priority issue during the TC office
hours a few days ago, and Dan Smith has said it elsewhere in this
thread. The chances of getting work done is proportional to the shared
understanding and value of the thing being proposed, including
risk/size/complexity etc.

Here are two concrete examples from part time contributors for nova:

1.
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/rebuild-keypair-reset.html

2.
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/scaleio-ephemeral-storage-backend.html

#1 is already merged for queens (has been for awhile now). It's a global
feature (not vendor backend specific) and not very complicated. The only
downside is it's an API change so we're stuck supporting it forever if
it turns out to be a bad idea.

#2 has been getting re-proposed for several cycles now (even before it
was eventually approved in Pike). It's a large single-vendor change
which piles onto existing technical debt. There is really only
motivation from anyone at Dell/EMC to get this done and therefore it
doesn't get much review so it continues to trudge forward. This isn't
because we don't like those people (Feodor has done a lot of great work
in nova over the years, and Eric has been very patiently rebasing this
change and requesting review without being pushy). It's because we only
have so many people doing reviews and we have higher priorities to spend
our review time on - or we have other low priority blueprints which
simply have higher shared value.

How do we solve that problem? Get someone from Dell/EMC to be full time
active in Nova for a year or more and build the trust of the core team
to want to review this change, and trust that the contributors will be
around to maintain it after it's merged? That's not a realistic solution.

We could dig up the slots/runways idea where we essentially do Kanban
and this gets queued up and the core team must get it in eventually to
start new work, regardless of priority.

I don't have an answer. There are options. The 1 year release idea
doesn't magically solve this problem. And arguably doing 3 intermediate
releases per year, if we did that to solve the "missed the 1 year boat"
issue, would add stress to the

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

2017-12-16 Thread Kashyap Chamarthy

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

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
how is this new proposal of 'one coordinated release per year' going to
address the following:

If your spec didn't make into this year's coordiated release, then
does it have to 'sit out' for one whole year? 

The shorter release cycle argument addresses that by not coupling specs
to a single release -- where specs can be submitted regardless of a
release in question.  Meanwhile, code development of the feature can
happen over several cycles.  And periodically re-evaluate it in light of
new evidence and design discussions.

As it stands[2], this problem seems mitgated by moving specs across
releases and re-approving them (insofar as they make sense).  Maybe in
current times, the above specs issue is 'non-problem'.  Happy to be
corrected.

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html
-- Re-evaluating the suitability of the 6 month release cycle

[2] https://specs.openstack.org/openstack/nova-specs/readme.html

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-16 Thread Kashyap Chamarthy

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 official
> > contributor gathering per year sounds fine.  And for those that need
> > more face time, people would continue to organize informal meetups.  But
> > admittedly, this shifts the logistics apsect onto contributors -- that's
> > probably okay, many other contributor communities self-organize meetups.

[...]

> 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 community.

Hi, we both agree.  I empathize with the Visa troubles.  I actually said
that the main official contributor gathering (PTG) should remain.
Didn't mean to imply that the informal meetups MUST be held; it's
only optional.

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread Thomas Goirand

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 backporting
> fixes to pike, ocata and newton. Newton isn't EOL yet *because* nova has
> held it up backporting fixes that we think are important enough to get
> in there before we EOL the branch.

I very much appreciate what has been done with the CVE fixes. Thanks a
lot for this, especially that it looked quite tricky and a way above the
level of patch I could backport by myself in a safe way.

> If you're talking about LTS, that's a different story, but please don't
> say upstream OpenStack doesn't care about backporting fixes. That might
> be a per-project statement, but in general it's untrue.

After re-reading myself, I noticed that it could be read in a variety of
ways. Sorry for this that's typical from me, maybe because I'm not a
native English speaker. :(

Let me attempt to correct myself.

First, it wasn't "upstream don't care about anyone, upstream is bad". It
was more: upstream currently doesn't have in place support so it can
care for a long enough time for its security bugfixes to be relevant to
distros.

More in details:

Upstream distributions are all advertising for 5 years support. For my
own case, and considering the last Debian release, Newton was out a year
ago, a bit before Debian Stretch freeze. Stretch was then released on
the 17th of June, while Newton was officially EOL on the 11th of
October. This means that, officially, Debian received 4 months of
official support during the lifetime of its release, which is supposed
to be at least 3 years, and preferably 5 (if we account the LTS effort).
So even without talking about OpenStack LTS, I hope everyone understand
that for me & Debian, the *official* security support is as good as
inexistant when dealing with Debian Stable.

Lucky, as always within this awesome OpenStack community, mostly
everyone from individual projects has been super helpful and helped when
I asked. However, even with very nice people, this helpfulness has
limits, and an official longer support would definitively help.

Anyway, all this was to say: I'm convinced that releasing less often
will help. I don't think backporting from master to Pike, Ocata and
Newton has so much value, but it's a lot of effort upstream. And in
Debian's case, Ocata backport wasn't needed. Even if we're not talking
about LTS, I'm sure having half the number of backports may help extend
the life of stable releases.

I hope it's clearer this time,
Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread James Penick

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.
>
> Assuming doubling the length of the cycle has no impact on the
> _importance_ of the thing the 20% person is working on, relative to
> project priorities, then the longer cycle just means they have to
> continuously rebase for a longer period of time.
>

+1, I see yearly releases as something that will inevitably hinder project
velocity, not help it.

-James
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread Matt Riedemann


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 EOL yet *because* nova has 
held it up backporting fixes that we think are important enough to get 
in there before we EOL the branch.


If you're talking about LTS, that's a different story, but please don't 
say upstream OpenStack doesn't care about backporting fixes. That might 
be a per-project statement, but in general it's untrue.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread Thomas Goirand

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 _support it_. Let distros pick those up when they need to 
> ship
> new features.

I don't think this will happen.

> Let users jump ahead for a few projects when they need the bug fixes.

And that, I don't agree. New releases aren't to fix bugs, bugs should be
fixed in stable too, otherwise you face new issues trying to get a
bugfix. And that's why we have stable.

> I understand the belief that nobody will run the intermediaries.

Not only that. Everyone is lagging a few release behind, and currently,
upstream OpenStack don't care backporting to older releases.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread Dmitry Tantsur


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 time between freeze and release is better to
refine the testing part. The cycle as it is, especially for people working
both upstream and downstream at the same time, is complicated enough.


Nothing in this proposal is talking about a longer time between feature
freeze and release, as far as I know (maybe I missed that somewhere).


It does not talk about this. But I think that it does not make sense without 
that.
IMHO.



In that regard, the one year cycle does not make the release any more
stable, it just means a bigger pile of stuff dumped on you when you
finally get it and upgrade.


Not if you commit to work on stabilization only (which in turn would allow us 
to be more confident that PASS jobs means that things are really working not 
just in DevStack).



If people could commit to work on stabilization only, we could do the same even 
with 3 months cycle. 2 months for features, 1 month for stabilization could 
actually work very well.


But so far 100% of people I've seen talking about stabilization only talked 
about it when it did not cut their features.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread Thierry Carrez

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 coordinated and tested
> much like the current release process. That means that anyone is who
> upgrading faster will be forced to wait for yearly releases because they
> are the only ones they know to be 'stable'.
> 
> I'm actually one of the 20% developers upstream (although I'm trying to
> change that), and my experience is actually the opposite. I like the
> shorter release times, I'd find that longer releases will make it much
> harder and longer waits to get anything in. With the 6 month cadence I
> know that if I miss a deadline for one release, the next one is around
> the corner. I've never had issue following up in the next release, and
> often if a feature or bug fix misses a release, in my experience the
> core team does a good job of making it a bit more of a priority. With
> yearly releases I'd be waiting for a year to get my code into a stable
> coordinated release, and then longer for that code to be deployed as
> part of an upgrade to a stable release. And I do often miss release
> deadlines, and that yearly wait would drive me mad.
> [...]

That is excellent feedback. Thanks Adrian!

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-15 Thread Luigi Toscano



- 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 better to
> > refine the testing part. The cycle as it is, especially for people working
> > both upstream and downstream at the same time, is complicated enough.
> 
> Nothing in this proposal is talking about a longer time between feature
> freeze and release, as far as I know (maybe I missed that somewhere).

It does not talk about this. But I think that it does not make sense without 
that.
IMHO.

> 
> In that regard, the one year cycle does not make the release any more
> stable, it just means a bigger pile of stuff dumped on you when you
> finally get it and upgrade.

Not if you commit to work on stabilization only (which in turn would allow us 
to be more confident that PASS jobs means that things are really working not 
just in DevStack).

-- 
Luigi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 installing everything from source by default?


I've been struggling to catch up and haven't gotten through the office
hours log yet, but this summarizes the thing that keeps bounding
through my mind.  But it seems to me that much of the reaction to
ttx's proposal gets into things that are not directly
development-cycle-related.  It feels like we are continuing to treat
symptoms and not actually address root causes.

I think #1 on our top-wanted list for the Board needs to be to address
these root causes.  Continuing to not do this will become an
existential problem for OpenStack.  Look at the situation with Nova
and the amount of energy spent on trying to improve things there
without actually being able to address the real problems.  Some of
these problems are structural to the software, some of them are the
massive amount of inertia that a 6 year old project that needs to be
backward-compatible  inevitably carries.


Can you give some specific examples here? What are we spending massive 
amounts of time on that aren't addressing real problems? 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?




The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.


Again, specific examples please. Is Nova somehow breaking compatibility 
every other week which is making upgrade impossible? I'm under the 
impression, maybe wrongly so, that the Nova team bends over backward 
trying to make sure we don't screw people doing upgrades as much as we 
can, at least across N-1 release boundaries. This is why we have 
microversions in the API. This is why we put in blocker schema 
migrations so that you can't move forward until you've performed online 
data migrations. Remember online data migrations? That's the thing where 
you don't have your control plane down for 8 hours running "nova-manage 
db sync". Writing code that migrates date at runtime across multiple 
cells and databases is not fun. If we're doing that for no apparent 
benefit, then we should stop I guess.




Clint brought up Swift earlier in the thread, and I think that is the
counter-example of what can happen with well-defined interfaces and
stable APIs.  Swift has been successful from the start with their
release model and fitting it into the overall OpenStack releases.
Why?  Because it does one thing, does it damn well, and does it with a
VERY stable API.  Some of the newer projects have also been able to
operate in this mode.


What is unstable about the compute API (assuming Nova is guilty of 
having unstable APIs here)?




Even with the differences in how they were created, Cinder and Neutron
are still tightly tied to Nova in terms of upgrades and the
requirements to keep them coordinated in specifically controlled
releases.


I said this elsewhere in this thread, but how so? You can definitely run 
mixed versions of these services as they communicate over REST APIs. 
Cinder and Nova are using microversions. Neutron isn't, but uses API 
extensions to indicate if a feature is available in the API or not, 
which Nova leverages. The shared library thing I get, but hasn't that 
been a solved problem for years now (run the services in venvs, 
containers, etc)? What specifically keeps people from being able to run 
old Nova and newer Cinder/Neutron and vice-versa?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 unless they are coordinated and tested
much like the current release process. That means that anyone is who
upgrading faster will be forced to wait for yearly releases because they
are the only ones they know to be 'stable'.

I'm actually one of the 20% developers upstream (although I'm trying to
change that), and my experience is actually the opposite. I like the
shorter release times, I'd find that longer releases will make it much
harder and longer waits to get anything in. With the 6 month cadence I
know that if I miss a deadline for one release, the next one is around
the corner. I've never had issue following up in the next release, and
often if a feature or bug fix misses a release, in my experience the
core team does a good job of making it a bit more of a priority. With
yearly releases I'd be waiting for a year to get my code into a stable
coordinated release, and then longer for that code to be deployed as
part of an upgrade to a stable release. And I do often miss release
deadlines, and that yearly wait would drive me mad.

The original goal for our cloud deployment was 1 release behind the
latest, or latest if no noticeably conflicting or potentially breaking
changes, with our own CI helping us ensure that. We sadly, like most
deployers, didn't live up to that goal purely because of what is now a
lot of technical debt we are paying off. Now we are paying off that
technical debt, and our release/upgrade cadence has improved, and
ideally we will get to the point of running latest releases again. As a
developer who does a bit of operations, I don't like the idea of yearly
releases because it means that those are my only safe option to upgrade
to, when in truth getting stability and bug fixes in sooner (or at least
potentially sooner) is where we want to be. Yes we can use master but
using master requires a lot of per project knowledge as to what is being
merged in at that time and what specs are being worked on, because, as
well as we all try to keep master stable, in introducing larger changes
there are always times when a few little things aren't quite right until
all the related reviews for a given feature of bug are merged. Tagged
milestones work, but the safety of a coordinated release is still much
better and requires less potential pain.

We are also one of those weird deployers that at times runs wildly
different versions of the various openstack components, with a large
amount of our own testing to help us ensure our cloud still operates
smoothly. We like smaller releases, because it lets us do incremental
upgrades to services with less features or changes, and helps us ensure
that no major version imbalance will cause any breaks. Larger yearly
releases gives us far less choices in the matter, and could in fact
potentially make this harder.

My other worry is that this proposal still feels related to the LTS
problem because it forces the community to now ensure safe upgrades
between much larger yearly releases. Effectively this forces us to now
support skip releases for 1 release back, while calling it something
else. It puts a larger burden on everyone as well since the releases are
much bigger (more changes to read through and compare), and more likely
to break during upgrade, thus likely making most deployers less likely
to upgrade until others have potentially fixed the pain or written up
how to avoid it thus pushing them even further behind. I may be reading
into this a little, but this proposal in a large part feels like a push
towards something closer to what LTS maintainers want releases to look
like, rather than what might be good for everyone else.

The other thing I really don't like is community goals being set once a
year. Some may be done faster than others, and we may want to introduce
new ones partway through the year. It assumes on a project as big and
complex as openstack we can alway see a full year ahead in perfect
clarity. I don't even think goals should have to always be bound to one
release as it is. Thierry himself said: "having one full year to
complete those will let us tackle more ambitious goals", which makes me
wonder, why can't we now set a goal that covers two releases, with its
intended end target being the following release, and set tasks that need
to completed in the first release of the two? This does not require a
yearly release, and while I get that single release goals will get more
priority, that's mostly a problem of management which will exist in
yearly releases (and goals) anyway.

If another part of the goal here is to lower overheads and management
effort, then PTLs can hold office for two releases, we can drop the
summit to once a year, etc. These

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

2017-12-14 Thread Zhenyu Zheng

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 community.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Zhenyu Zheng

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 need
> more face time, people would continue to organize informal meetups.  But
> admittedly, this shifts the logistics apsect onto contributors -- that's
> probably okay, many other contributor communities self-organize meetups.
>
> [...]
>
> --
> /kashyap
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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 community.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Adrian Turjak

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 like the current release process. That means that anyone is who
upgrading faster will be forced to wait for yearly releases because they
are the only ones they know to be 'stable'.

I'm actually one of the 20% developers upstream (although I'm trying to
change that), and my experience is actually the opposite. I like the
shorter release times, I'd find that longer releases will make it much
harder and longer waits to get anything in. With the 6 month cadence I
know that if I miss a deadline for one release, the next one is around
the corner. I've never had issue following up in the next release, and
often if a feature or bug fix misses a release, in my experience the
core team does a good job of making it a bit more of a priority. With
yearly releases I'd be waiting for a year to get my code into a stable
coordinated release, and then longer for that code to be deployed as
part of an upgrade to a stable release. And I do often miss release
deadlines, and that yearly wait would drive me mad.

The original goal for our cloud deployment was 1 release behind the
latest, or latest if no noticeably conflicting or potentially breaking
changes, with our own CI helping us ensure that. We sadly, like most
deployers, didn't live up to that goal purely because of what is now a
lot of technical debt we are paying off. Now we are paying off that
technical debt, and our release/upgrade cadence has improved, and
ideally we will get to the point of running latest releases again. As a
developer who does a bit of operations, I don't like the idea of yearly
releases because it means that those are my only safe option to upgrade
to, when in truth getting stability and bug fixes in sooner (or at least
potentially sooner) is where we want to be. Yes we can use master but
using master requires a lot of per project knowledge as to what is being
merged in at that time and what specs are being worked on, because, as
well as we all try to keep master stable, in introducing larger changes
there are always times when a few little things aren't quite right until
all the related reviews for a given feature of bug are merged. Tagged
milestones work, but the safety of a coordinated release is still much
better and requires less potential pain.

We are also one of those weird deployers that at times runs wildly
different versions of the various openstack components, with a large
amount of our own testing to help us ensure our cloud still operates
smoothly. We like smaller releases, because it lets us do incremental
upgrades to services with less features or changes, and helps us ensure
that no major version imbalance will cause any breaks. Larger yearly
releases gives us far less choices in the matter, and could in fact
potentially make this harder.

My other worry is that this proposal still feels related to the LTS
problem because it forces the community to now ensure safe upgrades
between much larger yearly releases. Effectively this forces us to now
support skip releases for 1 release back, while calling it something
else. It puts a larger burden on everyone as well since the releases are
much bigger (more changes to read through and compare), and more likely
to break during upgrade, thus likely making most deployers less likely
to upgrade until others have potentially fixed the pain or written up
how to avoid it thus pushing them even further behind. I may be reading
into this a little, but this proposal in a large part feels like a push
towards something closer to what LTS maintainers want releases to look
like, rather than what might be good for everyone else.

The other thing I really don't like is community goals being set once a
year. Some may be done faster than others, and we may want to introduce
new ones partway through the year. It assumes on a project as big and
complex as openstack we can alway see a full year ahead in perfect
clarity. I don't even think goals should have to always be bound to one
release as it is. Thierry himself said: "having one full year to
complete those will let us tackle more ambitious goals", which makes me
wonder, why can't we now set a goal that covers two releases, with its
intended end target being the following release, and set tasks that need
to completed in the first release of the two? This does not require a
yearly release, and while I get that single release goals will get more
priority, that's mostly a problem of management which will exist in
yearly releases (and goals) anyway.

If another part of the goal here is to lower overheads and management
effort, then PTLs can hold office for two releases, we can drop the
summit to once a year, etc. These things do not need to be bound to the
release

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

2017-12-14 Thread Thomas Goirand

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?
> 
> -- Ed Leafe

I used to package each and every b1, b2 and b3, be ready for rc1, and be
the first to release a working *and tested* release of OpenStack in
Debian. Since I'm no longer paid to do that, I just can't. I already
skipped Ocata, and yes, I will ignore these, and start the packaging
work *after* the official release. That is of course, unless some
companies offer to sponsor my work again... So far, each and every of
such proposal went to nowhere.

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Michał Jastrzębski

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 releases, the harder they are to deliver
> - the main problem newcomers may have today, is that the release process is
> very disruptive if they have not completed their feature in time for the
> next cut, and not getting it in time will mean a 6 months delay, which is
> very frustrating.

I agree with these points. I would also add that besides that bigger
releases are hard to deliver, stable branches are harder to maintain
as time goes. By that I mean:
1. bug is submitted
2. bug is fixed in master
3. bug is backported to stable

As time goes discrepancy between master and stable grows and backports
are more expensive. Also it will lower the cadence of "this bug is
fixed by new feature" and could potentially mean users/ops will have
to suffer it for longer time.

> As a consequence, I would rather propose:
> - a longer cadence for stable releases
> - a quicker cadence for intermediary releases (release early, release
> often...)

I agree with that approach. With lightweight releases (but still
releases so some cross-community testing is involved, even if only
automated one) we leave decision to operators to either wait for a
year, upgrade in smaller chunks with some testing or chase master with
nearly no testing.

> A longer cadence for stable release would mean that we pick a duration
> between stable branches that would fit our users' need and that is a
> multiplier of the shorter release.  Based on the interview we conducted on
> our user base a year and a half ago, it seemed that 18mo was the right
> cadence, but we could easily poll the wider OpenStack user base to have
> confirmation.  The justification we got for an 18 month cadence was that it
> was itself a divider of most user hardware life-cycle (3 years) and would
> help in their overall life-cycle management (ie they can decide to upgrade
> their hw once in the duration, or not and get to a new version at hw renewal
> every 3 years).
>
> A quicker cadence for intermediary release would mean that instead of
> creating a branch per release, we would only tag the various project
> branches for a release, validating that integration tests and fixes are
> aligned at this point.  Distributions could independently decide to provide
> these release and create their own branch to maintain those, but this would
> not be the burden of the overall project.   As a consequence of the quicker
> cadence, the integration milestone duration should be reduced to something
> like 2 or 3 weeks.  Switching to tagging a release instead of branching,
> should allow for almost uninterrupted merge request, to the exception of the
> integration period when only integration fixes should be (temporarily)
> accepted, but overall simplifying what one has to do to resume his work from
> one version to another.  Also, with a quicker release cycle, the impact of
> missing the window would be less penalizing, which I believe is a big part
> of the newcomers frustration with the project.  If we were going with
> 18month stable, then 3 month or 1.5 months intermediary releases would be my
> recommendation.
>
> What would that mean for summits? I would think that we could only have one
> "worldwide" summit yearly, with the ability to have regional summits in
> between.
> What would that mean for PTG? I would propose to keep a 6 monthly cadence
> for in person PTG, but formalize the creation of a 3 monthly virtual project
> gathering over a period of 48h.  No cross project topics would happen in
> those.
>
> As a consequence of this I think we would have:
> - a stable branch lifecycle which is more aligned with our user base
> - the ability for fast user to run from master "tagged version"
> - the ability for distros to differentiate on the model the adopt with
> respect to the intermediary release
> - less frustration for newcomers
> - a project that moves faster
>
> Thanks for taking the time to read this proposal.
>
> Nick
>
>
>
> On Wed, Dec 13, 2017 at 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 time to events, and generally the impression
>> that there is less time to get things done. Milestones in the
>> development cycles are mostly useless now as they fly past us too fast.
>> A lot of other people reported that same feeling.
>>
>> As our various components mature, we have less quick-paced feature
>> development going on. As more and more people adopt OpenStack, we are
>> more careful about not breaking them,

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 cycle as it is, especially for people working both 
upstream and downstream at the same time, is complicated enough.


Nothing in this proposal is talking about a longer time between feature 
freeze and release, as far as I know (maybe I missed that somewhere).


In that regard, the one year cycle does not make the release any more 
stable, it just means a bigger pile of stuff dumped on you when you 
finally get it and upgrade.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Dean Troyer

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 default?

I've been struggling to catch up and haven't gotten through the office
hours log yet, but this summarizes the thing that keeps bounding
through my mind.  But it seems to me that much of the reaction to
ttx's proposal gets into things that are not directly
development-cycle-related.  It feels like we are continuing to treat
symptoms and not actually address root causes.

I think #1 on our top-wanted list for the Board needs to be to address
these root causes.  Continuing to not do this will become an
existential problem for OpenStack.  Look at the situation with Nova
and the amount of energy spent on trying to improve things there
without actually being able to address the real problems.  Some of
these problems are structural to the software, some of them are the
massive amount of inertia that a 6 year old project that needs to be
backward-compatible  inevitably carries.

The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.

Clint brought up Swift earlier in the thread, and I think that is the
counter-example of what can happen with well-defined interfaces and
stable APIs.  Swift has been successful from the start with their
release model and fitting it into the overall OpenStack releases.
Why?  Because it does one thing, does it damn well, and does it with a
VERY stable API.  Some of the newer projects have also been able to
operate in this mode.

Even with the differences in how they were created, Cinder and Neutron
are still tightly tied to Nova in terms of upgrades and the
requirements to keep them coordinated in specifically controlled
releases.

Outside of those three projects, what others are experiencing the
sorts of problems being discussed here?  Is this (mostly) only a
problem the three largest and tightly-coupled projects?  In the
current environment I do not see any of our corporate sponsors
stepping up to un-couple those three, but for the rest it seems like
Doug's suggestion goes a long way toward addressing problems being
brought up here.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Doug Hellmann


> 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 like we
>> are always running elections, feature freeze is always just around the
>> corner, we lose too much time to events, and generally the impression
>> that there is less time to get things done. Milestones in the
>> development cycles are mostly useless now as they fly past us too fast.
>> A lot of other people reported that same feeling.
>> 
>> As our various components mature, we have less quick-paced feature
>> development going on. As more and more people adopt OpenStack, we are
>> more careful about not breaking them, which takes additional time. The
>> end result is that getting anything done in OpenStack takes more time
>> than it used to, but we have kept our cycle rhythm mostly the same.
>> 
>> Our development pace was also designed for fast development in a time
>> where most contributors were full time on OpenStack. But fewer and fewer
>> people have 100% of their time to dedicate to OpenStack upstream
>> development: a lot of us now have composite jobs or have to participate
>> in multiple communities. This is a good thing, and it will only
>> accelerate as more and more OpenStack development becomes fueled
>> directly by OpenStack operators and users.
>> 
>> In another thread, John Dickinson suggested that we move to one-year
>> development cycles, and I've been thinking a lot about it. I now think
>> it is actually the right way to reconcile our self-imposed rhythm with
>> the current pace of development, and I would like us to consider
>> switching to year-long development cycles for coordinated releases as
>> soon as possible.
>> 
>> What it means:
>> 
>> - We'd only do one *coordinated* release of the OpenStack components per
>> year, and maintain one stable branch per year
> 
> 
> So I want to zero in on this part of the proposal.
> 
> It feels like the major driving factor for frustration with the 6 month 
> cadence
> is the weight of the coordinated release versus the value, both for developers
> and users.
> 
> But, I wonder, why do we put so much emphasis on this one process?
> 
> One thing I've always admired about Swift was how immune to the cadence Swift
> appears to be.
> 
> If a set of enthusiastic developers shows up mid-cycle and starts hammering on
> a new feature, there's no angst about whether or not it can be done "this
> release". It's worked on, Swift moves forward, and when it is done, Swift
> releases.
> 
> We have this amazing tool that lets us get away with not doing the hard work
> Swift did to encapsulate itself. Zuul has enabled us to test all the projects
> that want to co-gate together as one. This allows co-dependencies to creep in
> under the covers. We have something that, on first look, appears to be
> micro-service-architecture, but then in reality, behaves like a massive
> monolithic piece of software.
> 
> But maybe we're papering over the real problem. Maybe we need to stop working
> so hard to coordinate these releases.
> 
> As projects mature, I'd expect some to slow down and some to speed up. Glance,
> for instance, is in perpetual maintenance mode. Nova is currently in a pretty
> heavy debt pay down state and still landing features. Neutron too. So I'd
> expect Glance to make frequent small releases of newly fixed items. Nova might
> need to do a slower release while a refactor happens, and then a few 
> follow-ups
> to get fixes and small enhancements out.
> 
> I understand you mentioned the intermediate release tag and practice. I'm
> suggesting that we should focus on getting _everyone_ on that train. I don't
> think this works without such an effort.
> 
> We can keep the release name cadence. But then we get the best of both worlds.
> 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 _support it_. Let distros pick those up when they need to 
> ship
> new features. Let users jump ahead for a few projects when they need the bug
> fixes. And then once a year, have a flag day where we all stop, and make an
> assertion that we've done some things, achieved some goals, and suggest that
> you upgrade all the components to at least that version, and that we'll make
> sure you can do that from the last big version.
> 
> I understand the belief that nobody will run the intermediaries. If we don't
> make them work independently of other projects, nobody will. But if we do, and
> if we make sure our interfaces are solid enough to advance components at a
> disjoint pace, then users will in fact start to do just that, and we'll retain
> the faster feedback cycle,

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

2017-12-14 Thread Jeremy Stanley

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, Pike, or Ocata.
[...]

Sounds fairly similar to the conclusion the fast-forward upgrades
discussions arrived at. I don't think there are any major objections
to this plan, people just need to work on an implementation.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Luigi Toscano

- 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 always a rush at the Feature Freeze point in a cycle to get things
> in, or they will be delayed for 6 months. With the year-long cycle, now
> anything missing Feature Freeze will be delayed by a year. The long cycle
> also means that a lot more time will be spent backporting things to the
> current release, since people won’t be able to wait a whole year for some
> improvements.
> 
> Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).

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 cycle as it is, especially for people working both 
upstream and downstream at the same time, is complicated enough.

If you trust master, as others suggested in this thread, just use master. Let 
people that wants stable releases use them.

-- 
Luigi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 reelection. Reducing the frequency of
those extra activities would increase time dedicated to development.


What does a PTL need to achieve in a term beyond managing a release? How 
many PTLs come into the position with a docket of major changes they 
want to implement in each project? Seems like that would be really 
disruptive to the flow of a team.


Or is the achievement equal to the number of blueprints merged? If so, 
that has to be scoped to the complexity and priority of the blueprint, 
who is doing the work and how many people in the core team are helping 
to get them through, which is not really something fully in the PTLs 
control.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Dan Smith

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, based on user
> surveys, it is only the major 6-month named releases that are
> deployed, and even then, some time after their release.
>
> Integrated releases make sense for deployers. What does it mean if
> Nova has some new stuff, but it requires a new release from Cinder in
> order to use it, and Cinder hasn't yet released the necessary updates?
> Talking about releasing projects on a monthly-tagged basis just dumps
> the problem of determining what works with the rest of the codebase
> onto the deployers.

Similarly, right now we have easy and uniform points at which we have to
make upgrade and compatibility guarantees. Presumably in such a new
world order, a project would not be allowed to drop compatibility in an
intermediate release, which means we're all being forced into a longer
support envelope for versioned APIs, config files, etc.

If we did do more of what I assume Doug is suggesting, which is just tag
monthly and let the projects decide what to do with upgrades, then we
end up with a massively more complex problem (for our own CI, as well as
for operators) of mapping out where compatibility begins and ends
per-project, instead of at least all aiming for the same point in the
timeline.

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Clint Byrum

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 an upgrade well and the only supported
path out is through several upgrades.

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, Pike, or Ocata.

And then we keep doing that in perpetuity. This gives users 18 months
from one release to get it up and stabilized, and then start the upgrade
cycle again. It also gives them 2 targets to hit while they do that,
since they can try "the stable that just released" and "the prior one"
and not feel like they'll fall behind if the new release has issues and
they have to stay conservative.

Basically instead of doing the release less frequently, shift the value
of the release toward what our users need.

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 the
> corner, we lose too much time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.
> 
> As our various components mature, we have less quick-paced feature
> development going on. As more and more people adopt OpenStack, we are
> more careful about not breaking them, which takes additional time. The
> end result is that getting anything done in OpenStack takes more time
> than it used to, but we have kept our cycle rhythm mostly the same.
> 
> Our development pace was also designed for fast development in a time
> where most contributors were full time on OpenStack. But fewer and fewer
> people have 100% of their time to dedicate to OpenStack upstream
> development: a lot of us now have composite jobs or have to participate
> in multiple communities. This is a good thing, and it will only
> accelerate as more and more OpenStack development becomes fueled
> directly by OpenStack operators and users.
> 
> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for coordinated releases as
> soon as possible.
> 
> What it means:
> 
> - We'd only do one *coordinated* release of the OpenStack components per
> year, and maintain one stable branch per year
> - We'd elect PTLs for one year instead of every 6 months
> - We'd only have one set of community goals per year
> - We'd have only one PTG with all teams each year
> 
> What it does _not_ mean:
> 
> - It doesn't mean we'd release components less early or less often. Any
> project that is in feature development or wants to ship changes more
> often is encouraged to use the cycle-with-intermediary release model and
> release very early and very often. It just means that the minimum we'd
> impose for mature components is one release per year instead of one
> release every 6 months.
> 
> - It doesn't mean that we encourage slowing down and procrastination.
> Each project would be able to set its own pace. We'd actually encourage
> teams to set objectives for the various (now longer) milestones in the
> cycle, and organize virtual sprints to get specific objectives done as a
> group. Slowing down the time will likely let us do a better job at
> organizing the work that is happening within a cycle.
> 
> - 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 replace the second PTG for teams that need or want to meet
> more often.
> 
> - It doesn't mean less emphasis on common goals. While we'd set goals
> only once per year, I hope that having one full year to complete those
> will let us tackle more ambitious goals, or more of them in parallel.
> 
> - It doesn't simplify upgrades. The main issue with the pace of
> upgrading is not the rhythm, it's the imposed timing. Being forced to
> upgrade every year is only incrementally better than being forced to
> upgrade every 6 months. The real solution there is better support for
> skipping releases that don't matter to you, not longer development cycles.
> 
> - It doesn't give us LTS. The cost of maintaining branches is not

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

2017-12-14 Thread Sven Anderson

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 of CD, but CD and OpenStack is nothing but a wet
dream. That's why I don't think, the 1-year release proposal is about
cutting travel costs. Compared to the costs of the release production
upstream and downstream, travel costs are just a joke. I fully support the
1-year cycle, not because I think it's good to have fewer releases in
general (the opposite is true, I like "release early and often"), but
because I think it's a necessary adaption to reality of OpenStack
development. Release production upstream and downstream creates a _huge_
overhead at the moment, if we like that fact or not, and cutting this
overhead in half is great! In the end the release production is done in
large parts by the same developers that develop upstream as well, and it
would free a lot of resources to do actual upstream development.

Of course, in the perfect world, upstream OpenStack would be a continuous
release-free stream of fresh and bug free software, that people can pull
downstream releases from whenever they like. But that's not the reality, at
least not as long the scope of the product is broader than "Nova on
Devstack". And I honestly don't see a project like OpenStack be "CD'able"
in a foreseeable future. So, to reach CD (which, again, would be awesome)
you have a dependency chain like "better test coverage" -> "shorter
stabilization phase" -> "more frequent releases" -> "CD". So, the time we
reach a stabilization phase of 0 days, that is, no stable branches are
required in general, we reached true CD. But I don't see stabilization
becoming shorter or easier, rather the opposite, because OpenStack becomes
more and more complex and featureful. So, as long as we can't achieve that,
we have to bite the bullet and adapt release cadence to the stabilization
and production efforts, if we like it or not.

BTW. I don't see the 1-year release connected to the frequency of
face-to-face meetings (PTG, Summit, ...), which I think should _not_ be
reduced.

Cheers,

Sven
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 think the idea deserves plenty of consideration, but my initial
> reaction has been that it is symptomatic care to ease the impact of
> problems, rather than a cure for whatever the disease might be.

We can take it from multiple angles.

It takes a lot of time to get anything merged, because getting code
reviewed takes a long time, because we are lacking core reviewers,
because becoming a core reviewer is difficult, because it's a role
invented in simpler times. We have tried to fix the disease for a while
without much success. It may be time to ease the pain ?

We have more and more part-time contributors, which is a good thing.
Users of OpenStack are getting more involved in upstream development,
but hey generally can't spend more than 20% of their time upstream.
Compared to people that can spend 4 times as much, getting anything done
(not just getting code reviewed) roughly takes 4 times as long. It's no
wonder 20% people have a difficult experience trying to contribute in a
cycle designed around the needs of 80% people.

In cross-project work and smaller projects, we end up discussing
one-year worth of changes every 6 months. There is not time to implement
and work on everything we discuss. That tends to point to events
occurring too often, or "cycles" being too short.

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 reelection. Reducing the frequency of
those extra activities would increase time dedicated to development.

So yes it's a series of symptoms caused by different diseases, but the
fact that we use a development cycle that was designed for different
times and needs seems to be in all cases an aggravating factor...

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Nick Barcet

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 that the release process is
very disruptive if they have not completed their feature in time for the
next cut, and not getting it in time will mean a 6 months delay, which is
very frustrating.

As a consequence, I would rather propose:
- a longer cadence for stable releases
- a quicker cadence for intermediary releases (release early, release
often...)

A longer cadence for stable release would mean that we pick a duration
between stable branches that would fit our users' need and that is a
multiplier of the shorter release.  Based on the interview we conducted on
our user base a year and a half ago, it seemed that 18mo was the right
cadence, but we could easily poll the wider OpenStack user base to have
confirmation.  The justification we got for an 18 month cadence was that it
was itself a divider of most user hardware life-cycle (3 years) and would
help in their overall life-cycle management (ie they can decide to upgrade
their hw once in the duration, or not and get to a new version at hw
renewal every 3 years).

A quicker cadence for intermediary release would mean that instead of
creating a branch per release, we would only tag the various project
branches for a release, validating that integration tests and fixes are
aligned at this point.  Distributions could independently decide to provide
these release and create their own branch to maintain those, but this would
not be the burden of the overall project.   As a consequence of the quicker
cadence, the integration milestone duration should be reduced to something
like 2 or 3 weeks.  Switching to tagging a release instead of branching,
should allow for almost uninterrupted merge request, to the exception of
the integration period when only integration fixes should be (temporarily)
accepted, but overall simplifying what one has to do to resume his work
from one version to another.  Also, with a quicker release cycle, the
impact of missing the window would be less penalizing, which I believe is a
big part of the newcomers frustration with the project.  If we were going
with 18month stable, then 3 month or 1.5 months intermediary releases would
be my recommendation.

What would that mean for summits? I would think that we could only have one
"worldwide" summit yearly, with the ability to have regional summits in
between.
What would that mean for PTG? I would propose to keep a 6 monthly cadence
for in person PTG, but formalize the creation of a 3 monthly virtual
project gathering over a period of 48h.  No cross project topics would
happen in those.

As a consequence of this I think we would have:
- a stable branch lifecycle which is more aligned with our user base
- the ability for fast user to run from master "tagged version"
- the ability for distros to differentiate on the model the adopt with
respect to the intermediary release
- less frustration for newcomers
- a project that moves faster

Thanks for taking the time to read this proposal.

Nick

On Wed, Dec 13, 2017 at 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 time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.
>
> As our various components mature, we have less quick-paced feature
> development going on. As more and more people adopt OpenStack, we are
> more careful about not breaking them, which takes additional time. The
> end result is that getting anything done in OpenStack takes more time
> than it used to, but we have kept our cycle rhythm mostly the same.
>
> Our development pace was also designed for fast development in a time
> where most contributors were full time on OpenStack. But fewer and fewer
> people have 100% of their time to dedicate to OpenStack upstream
> development: a lot of us now have composite jobs or have to participate
> in multiple communities. This is a good thing, and it will only
> accelerate as more and more OpenStack development becomes fueled
> directly by OpenStack operators and users.
>
> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for

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

2017-12-14 Thread Dan Smith

> 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 out how to solve the rebase conflicts instead of just
> focusing on her code.

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.

Assuming doubling the length of the cycle has no impact on the
_importance_ of the thing the 20% person is working on, relative to
project priorities, then the longer cycle just means they have to
continuously rebase for a longer period of time.

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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_  stick to what's tested together,
and we should keep testing things together, I also think we should be
more comfortable telling users to go ahead and install a new release of
Nova and feel confident they're going to be supported in doing so.

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.


Nova can certainly run with older versions of all the other projects. We 
communicate over (mostly) versioned REST APIs (glance v2.0 is fine for 
nova, keystone v3 is fine, cinder has microversions, and neutron exposes 
new API features using extensions).


I agree that it's a risk to run that way because it's not how we do CI 
testing, but it's totally possible and I agree that we should be telling 
people you can do this.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 significant done within the timeframe of a
cycle, which leads to frustration as you have to get your stuff
re-discussed and re-prioritized at the start of the next cycle.


If the change that the 20% person is trying to get done is not an actual 
priority for the project, and is significant, then yes it's going to 
take a long time because a stretched core team isn't going to prioritize 
helping to design, implement, review and support something that most 
people don't care about.


If the thing that the 20% contributor is pushing is not all that 
complicated and is shared as a need by many people (I'm thinking 
operators community here), then it's easier for the project maintainers 
as a whole to agree that it should be bumped up in priority. There are a 
few cases like this in nova in the last couple of releases (changing key 
on rebuild in queens, extend attached volume in pike).


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Chris Dent


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 consideration, but my initial
reaction has been that it is symptomatic care to ease the impact of
problems, rather than a cure for whatever the disease might be.

Frequently, the outcome that happens when band-aiding symptoms is
that there are a lot of unintended (and unexpected) consequences
that introduce more problems which require more band-aids, and so
on.

For example: if we go to a longer cycle, if some projects choose to
use intermediate or milestone-based releases, while others do not,
how do we manage upgrade (grenade) testing? What complexities will
that introduce?

Is there an opportunity here to decouple consumption of releases
from their creation? This is already the case. Most distributions
and deployments are months if not years behind master. The frequency
at which master is blessed as a release™ doesn't necessarily have to
be coupled with that.

If the core problem we're trying to solve for here is to not
discourage part time contribution, let's get to the root causes of
that. The cycle being too short seems unlikely as a _root_ cause.
Six months is a long time.

If there are multiple problems that we're trying to solve for, let's
be clear about what they are. This thread suggests that "too many
events" is a problem, but that's only associated with cycle length
because we choose for it to be, not because it has to be.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Clint Byrum

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 Forums, though important, 
> > hardly made it worthwhile for me to attend the summit (and in fact I 
> > skipped Sydney). On the other hand some devs got together and hashed out 
> > some plans for their projects. Personally, I feel the PTG is not working if 
> > we also have summits – and having two summits and one PTG will make things 
> > worse. Therefore I propose to scrap the PTG and add “design summits” back 
> > to the OpenStack summit. As a side effect this will be a better on-ramp for 
> > casual developers who can’t justify going to the PTG and ensure enough 
> > developers are on-hand to hear the operator’s feedback.
> 
> The original purpose of the summits were for the developers to get together 
> to plan what they would work on for the next few months. Over time, the big 
> money came pouring in, and they became huge marketing events, with developers 
> pushed off to the fringes. The recent PTGs have been refreshing because they 
> are more like the original events, where there is no distraction by the 
> corporate marketing machines, and we can focus on getting shit done.
> 
> My question is: if we only have a release once a year, why do we need two 
> Summits a year?
> 

Regional rotation seems the best reason to keep two per year.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Ed Leafe

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
> impossible to get something significant done within the timeframe of a
> cycle, which leads to frustration as you have to get your stuff
> re-discussed and re-prioritized at the start of the next cycle.

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. The 20% developer would be spending a greater 
proportion of her time figuring out how to solve the rebase conflicts instead 
of just focusing on her code.

I’m not saying that the advantages you mention aren’t real. I’m just pointing 
out that there are downsides to stretching things out.

-- Ed Leafe

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Ed Leafe

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






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Jeremy Stanley

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 participating
in software development.

If by "operators" you mean people who are unable or unwilling to
participate in developing software then I suspect attempting to
extend the PTG to that demographic will serve only as a distraction
from people trying to do high-bandwidth codevelopment on a team.

I personally prefer the first definition. Operators are often also
developers and vice versa. It's not one side against the other, but
to me the PTG is mostly about doing software development so
attendees should come prepared to roll up their sleeves and do that.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Julien Danjou

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 significant done within the timeframe of a
> cycle, which leads to frustration as you have to get your stuff
> re-discussed and re-prioritized at the start of the next cycle.
>
> I'm open to other ways to solve what is perceived by many as an
> untenable cadence -- but so far the only suggestion I got on this thread
> was that 20% people should really ask their manager to become 80%
> people. And I don't see that happening.

Yeah that does not seem realistic.

I like the way you state the problem actually: "it's just impossible to
get something significant done within the timeframe of a cycle, which
leads to frustration as you have to get your stuff re-discussed and
re-prioritized at the start of the next cycle".

So the first thing that comes to mind is that having a longer release
cycle will fix it.

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"?

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Ed Leafe

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 sure 
>> that we're all still working together well.
> 
> My entire point is that we should draw clearer lines around our API's and
> admit that we have a ton of tight coupling that requires us to release
> things in an integrated fashion.
> 
> While I agree, where we're at is a tightly coupled mess, what I don't agree
> with is that the answer is to keep shipping the mess.

I agree 100% with that sentiment. However, *until* we achieve something close 
to that, we have to continue to ship “this mess”. Taking a mess and shipping it 
separately doesn’t clean up the mess.


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 are struggling to recruit new core reviewers, so I think
>> reducing expectations and slowing down the pace could help there.
> 
> 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
> solves it.

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 significant done within the timeframe of a
cycle, which leads to frustration as you have to get your stuff
re-discussed and re-prioritized at the start of the next cycle.

I'm open to other ways to solve what is perceived by many as an
untenable cadence -- but so far the only suggestion I got on this thread
was that 20% people should really ask their manager to become 80%
people. And I don't see that happening. We 80% people can bury our heads
in the sand and pretend that we don't need the 20% people or somehow fix
them so they become 80% people. Fact is we have less and less of those
80% people and we fail to recruit enough of the many available 20%
people to be sustainable long-term.

I'm aware this solution is not perfect. I don't like the idea of
releasing less often, and I can see how intermediary releases might not
get used, leading to "minor releases" that would look like our current
milestones. Maybe the drawbacks outweigh the benefits. Open to other
suggestions :)

-- 
Thierry Carrez (ttx)

signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Fred Li

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 a lot to the vendors.
2. prefer longer development cycle to have more features and to
stabilize the release.
I don't think the reason 2 is valid, so I will ignore this. The reason
1 does exist.

But I don't think the the proposal to change release cycle to one year
is good enough to accept.
What image OpenStack community gives to customers if we change the
release cycle to 1 year? I guess there could be 2. The first one is
that OpenStack is mature enough. The second could be that OpenStack is
stepping down as fewer developers are working on it, thus the output
is not big enough. Considering the second reason, I don't think this
idea is good.

The problem some vendors cost is high to follow every single release
still exists. My proposal is OpenStack Foundation can adjust the
release strategy, like the first 6 months release is features
focused, and the next 6 months' is mainly bugs focused. I would say
that it is more a marketing strategy than a technical development
strategy to manage customers' expectation, and can probably help
vendors not to productize each release.

I also share my opinion about ptg/summit/mid-cycle here.
Despite how long the release cycle is, the engineers do need meet in
person periodically. My feeling (sorry, I don't have pretty convincing
figure) is around every 3 months. So design summit (or PTG) every 6
months is mandatory, as the developers need talk about cross-project
topics together, and it is easier to find sponsors supporting formal
events than others (e.g. mid-cycle). Mid-cycle can be decided by each
project team. And to save travel cost, to have the summit and ptg in
the same week and same city is an option.

My 1 cent.

On Thu, Dec 14, 2017 at 6:21 PM, Renat Akhmerov
 wrote:
> 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
> solves it.
>
>
> Yes, exactly.
>
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Regards
Fred Li (李永乐)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Sylvain Bauza

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 down our
> >> pace could be helpful to them and generally reduce stress in OpenStack
> >> development. I know people who can spend 100% of their time upstream can
> >> cope with our current rhythm. I just observe that we have less and less
> >> of those full-time people and need to attract more of the part-time one.
> >>
> >> If this proposal is not helping developers and making OpenStack
> >> development less painful, I don't think we should do it:)
> >
> > Given I have the luxury of working mostly full time upstream, I've
> > obviously got a skewed perspective on this whole discussion.
> >
> > I am interested in which part time developers are having issues keeping
> > up and how, i.e. are these core team members that don't feel they can be
> > good core reviewers if they aren't around enough to keep up with the
> > changes that are happening? I could definitely see a case like that with
> > some of the complicated stuff going on in nova like the placement and
> > cells v2 work.
>
> There was two kind of feedback.
>
> - 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 new core reviewers, so I think
> reducing expectations and slowing down the pace could help there.
>
>

Like others said, I don't see how slowing down the number of releases will
help those people to catch up with the project updates since features
should in theory be delivered at the same pace (if we don't loose developer
interests in developing features, which is one of my concerns).
Struggling with managing your day-to-day work really means you're in
trouble, and you need to find ways to prioritize your tasks, IMHO. Be
verbose, talk to your manager, try to find how you can increase time for
OpenStack. And yes, it's hard and I'm personnally facing problems too.

- People in projects that are more mature (or packaging projects) where
> the process overhead (coordinated releases, elections, PTG
> preparation...) ends up representing a significant chunk of the work.
> For those it felt like longer cycles would reduce that overhead and give
> them more time to do real work.
>
>
If we do intermediary releases, it doesn't really solve the problem either,
right?
There are actually two separate concerns from what I can read :
 - release coordination (tagging a milestone or branching a release)
 - governance and community coordination (electing a PTL or organizing a
PTG)

The former concern does seem to me less impactful now because thanks to a
couple of major improvements with Zuul and release management, we're less
depending on humans. And, again, doing intermediary releases would still
burn people's time, right ?
The latter is really a specific problem tied to a specific group of people
(namely the PTLs and the election team). Couldn't we rather review what
those people need to do and how we can help them to reduce the burden ?

> If we're talking about part time contributors that are contributing bug
> > fixes here and there, docs patches, random reviews, I'm not sure how
> > this is substantially better for them.
>
> No, I'm more talking about someone who can dedicate one day per week to
> OpenStack development, and who currently struggle to be part of a team
> where everyone has to be >80% to keep up with the rhythm.
>
> > We've said in this thread that project teams are encouraged to still do
> > intermediate releases, often. And we're still going to be working on
> > features, so how does that help slow things down for the part time
> > contributor?
>
> My hope is that by reducing the "coordinated release" pressure, we'd
> encourage project teams to adopt a rhythm that is more natural for them.
> Some teams would still be pretty active with lots of intermediary
> releases, while some others would have an easier time.
>
>

Well, I do feel that if we decide to go with a 1-year timeframe for a
"coordinated" release, it would highly raise the price of that release.
Imagine what it means for someone who really desperately want to integrate
a feature that require some kernel update and fancy network driver thingy.
If you loose the target, you're a dead man for 1 year. Of course, you can
target an intermediary release but since we only "coordinate" yearly, how
can you be sure that packagers will ship your feature from that
intermediary release ?

> If *everyone* must slow down then that's going to be a problem I think,
> > unless we do something like alternating intermediate releases where
> > there are new features and then only bug fixes, something like

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

2017-12-14 Thread Clint Byrum

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 patches out-of-tree to
scale. Luckily, I'm told neither does Nova anymore, so maybe this will
get more natural.. well.. naturally.

Excerpts from Blair Bethwaite's message of 2017-12-14 18:39:33 +1100:
> 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
> https://trello.com/b/9fkuT1eU/nectar-openstack-versions for the current
> version snapshot.
> 
> On 14 Dec. 2017 18:00, "Clint Byrum"  wrote:
> 
> > 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 much about doing the whole integrated release dance so often.
> > >
> > > Is there any data about how operators approach this currently? Nectar
> > > (and I presume other large and/or loosely coordinated OpenStack
> > > clouds) has been running different projects across multiple versions
> > > for quite a while, sometimes 3 or 4 different versions. Coordinating
> > > upgrades in a federated cloud with distributed operations requires
> > > that we do this, e.g., our current Nova Newton upgrade has probably
> > > been in-train for a couple of months now.
> > >
> >
> > That's interesting. Can you share what you mean by running 3 or 4
> > different versions?
> >
> > Do you mean you mix versions in a single region, like, Pike keystone,
> > Ocata Nova, and Newton Neutron? Or do you mean you might have a region
> > running Pike, and another running Ocata, and another running Newton?
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Dmitry Tantsur


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 it worthwhile for me to attend the summit (and in fact I skipped 
Sydney). On the other hand some devs got together and hashed out some plans for 
their projects. Personally, I feel the PTG is not working if we also have 
summits – and having two summits and one PTG will make things worse. Therefore 
I propose to scrap the PTG and add “design summits” back to the OpenStack 
summit. As a side effect this will be a better on-ramp for casual developers 
who can’t justify going to the PTG and ensure enough developers are on-hand to 
hear the operator’s feedback.


The original purpose of the summits were for the developers to get together to 
plan what they would work on for the next few months. Over time, the big money 
came pouring in, and they became huge marketing events, with developers pushed 
off to the fringes. The recent PTGs have been refreshing because they are more 
like the original events, where there is no distraction by the corporate 
marketing machines, and we can focus on getting shit done.

My question is: if we only have a release once a year, why do we need two 
Summits a year?


That's a very good question. I'd see the opposite: PTG twice a year with a Forum 
after each release. And loop operators into PTGs more.




-- Ed Leafe



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Dmitry Tantsur


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 longer.


There is always a rush at the Feature Freeze point in a cycle to get things in, 
or they will be delayed for 6 months. With the year-long cycle, now anything 
missing Feature Freeze will be delayed by a year. The long cycle also means 
that a lot more time will be spent backporting things to the current release, 
since people won’t be able to wait a whole year for some improvements.

Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).


Yes, I'll admit I'm struggling with that part of the proposal too. We
could use intermediary releases but there would always be a "more
important" release.

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 that the pressure is reduced now that
we are past the hype peak...



There was quite a pressure all past releases for us. I don't quite expect it to 
end, until people proposing features start being more realistic about timelines.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Kashyap Chamarthy

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 around the
> corner, we lose too much time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.

Thanks for articulating it out loud.  FWIW, I share that same feeling to
an extent, especially as one of those people involved in mulitple
communities (the lower-layer components that OpenStack depends on) and
simply don't have the necessary bandwidth to keep up.

[...]

> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for coordinated releases as
> soon as possible.
> 
> What it means:
> 
> - We'd only do one *coordinated* release of the OpenStack components per
> year, and maintain one stable branch per year
> - We'd elect PTLs for one year instead of every 6 months
> - We'd only have one set of community goals per year
> - We'd have only one PTG with all teams each year

The above sounds reasonable to me.  

And it should (and will) reduce a lot of breathlessness and 'keeping the
pedal glued to the metal' feeling that comes from being unable to keep
up with things.  Not to mention, the OpenStack Foundation welcomes a bit
of breathing room from having to organize and coordinate so many events.

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 need
more face time, people would continue to organize informal meetups.  But
admittedly, this shifts the logistics apsect onto contributors -- that's
probably okay, many other contributor communities self-organize meetups.

[...]

> When ?

[...]

> So the year-long cycles would ideally start at the beginning of the
> year, when we would organize the yearly PTG. That said, I'm not sure we
> can really afford to keep the current rhythm for one more year before
> switching. That is why I'd like us to consider taking the plunge and
> just doing it for *Rocky*, and have a single PTG in 2018 (in Dublin).

Jumping right in sounds good.  Getting started immediately will also get
us to real world 'data' sooner, rather than dilly-dallying around.

[...]

> So... What do you think ?

I welcome this proposal.

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Renat Akhmerov

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
> solves it.

Yes, exactly.


Renat Akhmerov
@Nokia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Fred Li

On Thu, Dec 14, 2017 at 6:38 AM, German Eichberger
<german.eichber...@rackspace.com> 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 summit (and in fact I skipped
> Sydney). On the other hand some devs got together and hashed out some plans
> for their projects. Personally, I feel the PTG is not working if we also
> have summits – and having two summits and one PTG will make things worse.
> Therefore I propose to scrap the PTG and add “design summits” back to the
> OpenStack summit. As a side effect this will be a better on-ramp for casual
+1. If one of the purpose is to save developers' travel cost, this
idea works. Besides this, it is important for the developers to hear
voice from users/operators who attend the current summits.
> developers who can’t justify going to the PTG and ensure enough developers
> are on-hand to hear the operator’s feedback.
>
>
>
> German
>
>
>
> From: Tim Bell <tim.b...@cern.ch>
> Reply-To: "OpenStack Development Mailing 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: [openstack-dev] [all] Switching to longer development cycles
>
>
>
> The forums would seem to provide a good opportunity for get togethers during
> the release cycle. With these happening April/May and October/November,
> there could be a good chance for productive team discussions and the
> opportunities to interact with the user/operator community.
>
>
>
> 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.
>
>
>
> If there is consensus, I’d suggest to get feedback from openstack-operators
> on the idea. My initial suspicion is that it would be welcomed, especially
> by those running from distros, but there are many different perspectives.
>
>
>
> Tim
>
>
>
> From: Amy Marrich <a...@demarco.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: Wednesday, 13 December 2017 at 18:58
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Switching to longer development cycles
>
>
>
> I think Sean has made some really good points with the PTG setting things
> off in the start of the year and conversations carrying over to the Forums
> and their importance. And having a gap at the end of the year as Jay
> mentioned will give time for those still about to do finishing work if
> needed and if it's planned for in the individual projects they can have an
> earlier 'end' to allow for members not being around.
>
>
>
> The one year release would help to get 'new' users to adopt a more recent
> release, even if it's the one from the year previously as there is the
> 'confidence' that it's been around for a bit and been used by others in
> production. And if projects want to do incrementals they can, if I've read
> the thread correctly. Also those that want the latest will just use master
> anyways as some do currently.
>
>
>
> With the move to a yearly cycle I agree with the 1 year cycle for PTLs,
> though if needed perhaps a way to have a co-PTL or a LT could be implemented
> to help with the longer duties?
>
>
>
> My 2 cents from the peanut gallery:)
>
>
>
> Amy (spotz)
>
>
>
> On Wed, Dec 13, 2017 at 11:29 AM, Sean McGinnis <sean.mcgin...@gmx.com>
> wrote:
>
> On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote:
>> Hey
>>
>> On 13 December 2017 at 17:12, Jimmy McArthur <ji...@openstack.org> wrote:
>>
>> > 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 replace the second PTG for teams that need or want to meet
>> >> more often.
>> >>
>> > The PTG seems to allow greater coordination between groups. I worry that
>> > going back to an optional mid-cycle would reduce this
>> > cross-collaboration,
>> > while also reducing project face-to-face

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

2017-12-14 Thread Julien Danjou

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 new core reviewers, so I think
> reducing expectations and slowing down the pace could help there.

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
solves it.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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
>> development. I know people who can spend 100% of their time upstream can
>> cope with our current rhythm. I just observe that we have less and less
>> of those full-time people and need to attract more of the part-time one.
>>
>> If this proposal is not helping developers and making OpenStack
>> development less painful, I don't think we should do it:)
> 
> Given I have the luxury of working mostly full time upstream, I've
> obviously got a skewed perspective on this whole discussion.
> 
> I am interested in which part time developers are having issues keeping
> up and how, i.e. are these core team members that don't feel they can be
> good core reviewers if they aren't around enough to keep up with the
> changes that are happening? I could definitely see a case like that with
> some of the complicated stuff going on in nova like the placement and
> cells v2 work.

There was two kind of feedback.

- 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 new core reviewers, so I think
reducing expectations and slowing down the pace could help there.

- People in projects that are more mature (or packaging projects) where
the process overhead (coordinated releases, elections, PTG
preparation...) ends up representing a significant chunk of the work.
For those it felt like longer cycles would reduce that overhead and give
them more time to do real work.

> If we're talking about part time contributors that are contributing bug
> fixes here and there, docs patches, random reviews, I'm not sure how
> this is substantially better for them.

No, I'm more talking about someone who can dedicate one day per week to
OpenStack development, and who currently struggle to be part of a team
where everyone has to be >80% to keep up with the rhythm.

> We've said in this thread that project teams are encouraged to still do
> intermediate releases, often. And we're still going to be working on
> features, so how does that help slow things down for the part time
> contributor?

My hope is that by reducing the "coordinated release" pressure, we'd
encourage project teams to adopt a rhythm that is more natural for them.
Some teams would still be pretty active with lots of intermediary
releases, while some others would have an easier time.

> If *everyone* must slow down then that's going to be a problem I think,
> unless we do something like alternating intermediate releases where
> there are new features and then only bug fixes, something like that - up
> to the discretion of each project team as they see fit.
> 
> I haven't seen anyone mention this yet either, but if "slowing down"
> begins to look like we're entering maintenance mode, I don't think
> that's going to attract new developers and it's likely to mean long-time
> key maintainers are going to lose interest and start looking elsewhere
> to scratch their itches. It's hard to say what would happen. I can
> certainly keep myself busy with docs patches and bug fixes until the
> cows come home.

All good points.

It feels like we have to dive deeper into the consequences in terms of
release cadence (intermediary/coordinated) and in terms of stable branch
maintenance before we can make a call.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Thomas Goirand

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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 one.
> 
> 2) Keep the support cycle to a year
>     This would basically mean that as soon as there is a new release, the
>     previous one would become EOL ? This is what seems suggested here
>     and I'm really not confident this would be a great idea. It would force
>     people to upgrade within weeks after a new release to stay on a
> supported version.

There is also the intermediary solution, where branches would be
supported for 15 or 18 months, giving a 3-month or 6-month overlap.

> As some others have mentioned in the thread, there are pros and cons to
> moving to a
> year-long cycle and I think it's great that we are having this
> discussion as it will help
> us make an informed decision.

Yes! The proposal is really based on partial feedback I received, which
is why I think we should have this discussion publicly to explore the
consequences and decide how much of a good idea it would be (or not).

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-14 Thread Jaze Lee

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 companies is
just maintained, not develop forward.
No attractive feature is include in.
One reason is the IaaS does not need too much feature. If the vm is
ok, and can be
connected, It is ok. Let other people to develop it.
One reason is as public cloud goes popular, users have multiple
choices. Openstack is just one, and the less attractive one.
Only the company do not want, or not  allowed, to use public  cloud
may be want to use Openstack.
One reason is the time changed, right now every body talks about AI. I
attend one storage reference, all people talks about AI,
 they said, we will make storage more intelligent, if we do not do
this, we will be eliminated.

May be we should give new mission to Openstack to refresh it ?
Thanks a lot again.

2017-12-14 15:39 GMT+08:00 Blair Bethwaite :
> 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
> https://trello.com/b/9fkuT1eU/nectar-openstack-versions for the current
> version snapshot.
>
> On 14 Dec. 2017 18:00, "Clint Byrum"  wrote:
>>
>> 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 much about doing the whole integrated release dance so often.
>> >
>> > Is there any data about how operators approach this currently? Nectar
>> > (and I presume other large and/or loosely coordinated OpenStack
>> > clouds) has been running different projects across multiple versions
>> > for quite a while, sometimes 3 or 4 different versions. Coordinating
>> > upgrades in a federated cloud with distributed operations requires
>> > that we do this, e.g., our current Nova Newton upgrade has probably
>> > been in-train for a couple of months now.
>> >
>>
>> That's interesting. Can you share what you mean by running 3 or 4
>> different versions?
>>
>> Do you mean you mix versions in a single region, like, Pike keystone,
>> Ocata Nova, and Newton Neutron? Or do you mean you might have a region
>> running Pike, and another running Ocata, and another running Newton?
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
谦谦君子

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Blair Bethwaite

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
https://trello.com/b/9fkuT1eU/nectar-openstack-versions for the current
version snapshot.

On 14 Dec. 2017 18:00, "Clint Byrum"  wrote:

> 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 much about doing the whole integrated release dance so often.
> >
> > Is there any data about how operators approach this currently? Nectar
> > (and I presume other large and/or loosely coordinated OpenStack
> > clouds) has been running different projects across multiple versions
> > for quite a while, sometimes 3 or 4 different versions. Coordinating
> > upgrades in a federated cloud with distributed operations requires
> > that we do this, e.g., our current Nova Newton upgrade has probably
> > been in-train for a couple of months now.
> >
>
> That's interesting. Can you share what you mean by running 3 or 4
> different versions?
>
> Do you mean you mix versions in a single region, like, Pike keystone,
> Ocata Nova, and Newton Neutron? Or do you mean you might have a region
> running Pike, and another running Ocata, and another running Newton?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 much about doing the whole integrated release dance so often.
> 
> Is there any data about how operators approach this currently? Nectar
> (and I presume other large and/or loosely coordinated OpenStack
> clouds) has been running different projects across multiple versions
> for quite a while, sometimes 3 or 4 different versions. Coordinating
> upgrades in a federated cloud with distributed operations requires
> that we do this, e.g., our current Nova Newton upgrade has probably
> been in-train for a couple of months now.
> 

That's interesting. Can you share what you mean by running 3 or 4
different versions?

Do you mean you mix versions in a single region, like, Pike keystone,
Ocata Nova, and Newton Neutron? Or do you mean you might have a region
running Pike, and another running Ocata, and another running Newton?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Renat Akhmerov

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. Too part time.. Based 
on my observations, it’s very very difficult to weave a new developer with 
normal average skills (there geniuses, of course, but they are exceptions) into 
the project development if he/she randomly spends several days a month to 
contribute upstream. If we adjust the speed of development to make these people 
happy then we’ll be moving forward like turtles.

I would rather work on encouraging companies to allocate full time developers 
explaining them all the benefits of such approach. I know, I know, it’s not 
easy but it seems to me that everyone is suffering from the situation when devs 
only work on their priorities w/o taking responsibility for the overall project 
quality, and then suddenly realize that the project is almost dead just because 
it’s not interesting to anyone else who want to use it for slightly different 
use cases but can’t because it’s not mature enough (and hold on with 
contributing for the same reason). I strongly believe this is a serious issue. 
It feels to me that it used to be different years ago, people weren’t afraid to 
be more responsible for their projects.

So I agree that this is a problem but I’m not sure that making development 
cycles longer will solve it.

Despite all I said, I’m still for 1 year cycles. The main reason for me is that 
it seems like we spend much time for inter cycle activities, including 
preparation to PTGs and summits, releasing, taking care of FFEs and emergency 
back ports etc. I as a developer get distracted seriously from solving 
technically challenging tasks. And then it’s often hard to tune back to a 
needed wave. But many tasks require focus during a significant period of time 
to be solved. Sounds a little bit fuzzy probably but it’s an issue personally 
for me. Maybe because I’m also trying to combine development with PTLship, but 
still..

Thanks

Renat Akhmerov
@Nokia

On 14 Dec 2017, 12:02 +0700, Ed Leafe , wrote:
> 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 OpenStack. It is 
> free to do things its own way on its own schedule.
>
> 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 sure 
> that we're all still working together well.
>
> [0] https://blog.leafe.com/on_swift/
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 'nother thing.
> 
> It does not have API interdependencies with anything else in OpenStack. It is 
> free to do things its own way on its own schedule.

_this is exactly my point_

First, Swift has plenty of API interdependency. Swift consumes Keystone's
API just like everyone else. Swift also fronts a glance driver which is
optional to use. Trove backs things up to Swift.

The reason it doesn't feel like they're entangled with the rest of OpenStack
_is because they aren't_.

> 
> 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 sure 
> that we're all still working together well.
> 

My entire point is that we should draw clearer lines around our API's and
admit that we have a ton of tight coupling that requires us to release
things in an integrated fashion.

While I agree, where we're at is a tightly coupled mess, what I don't agree
with is that the answer is to keep shipping the mess.

I've said this before and honestly, I got crickets back in Atlanta for
saying it, but nova-compute should be renamed 'hypervisor'. Anything that
needs to run on a hypervisor should be in this service's world, and not
in the respective projects. Each hypervisor host is an endpoint of this
API, placement being the service discovery mechanism for that endpoint.

Neutron and Cinder would be treated as first-class API consumers of
the hypervisor API. If you want to upgrade cinder, go ahead, as long as
the hypervisor API version you have is supported by Cinder, Cinder can
control the volumes on it.

Right now we just can't do that. We know they were split out and we let
them share a filesystem and a network namespace on nova-compute and keep
a tight ratchet on that poorly defined API by releasing everything from
neutron agents to brick versions in lock-step. As long as we do that,
we're stuck with a massive monolith of a product to ship, and that is
likely not serving our users.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Blair Bethwaite

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 data about how operators approach this currently? Nectar
(and I presume other large and/or loosely coordinated OpenStack
clouds) has been running different projects across multiple versions
for quite a while, sometimes 3 or 4 different versions. Coordinating
upgrades in a federated cloud with distributed operations requires
that we do this, e.g., our current Nova Newton upgrade has probably
been in-train for a couple of months now.

-- 
Cheers,
~Blairo

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 more often.  I'd personally rather do away with milestones
> > altogether and just tag everything monthly, but some projects may
> > not be ready to do that and some may want to go more often (libraries
> > in particular).
> 
> 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, based on user surveys, it is only the major 6-month 
> named releases that are deployed, and even then, some time after their 
> release.
> 
> Integrated releases make sense for deployers. What does it mean if Nova has 
> some new stuff, but it requires a new release from Cinder in order to use it, 
> and Cinder hasn't yet released the necessary updates? Talking about releasing 
> projects on a monthly-tagged basis just dumps the problem of determining what 
> works with the rest of the codebase onto the deployers.
> 
> 

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_ stick to what's tested together,
and we should keep testing things together, I also think we should be
more comfortable telling users to go ahead and install a new release of
Nova and feel confident they're going to be supported in doing so.

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.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 OpenStack. It is 
free to do things its own way on its own schedule.

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 sure 
that we're all still working together well.

[0] https://blog.leafe.com/on_swift/

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 summit (and in fact I skipped 
> Sydney). On the other hand some devs got together and hashed out some plans 
> for their projects. Personally, I feel the PTG is not working if we also have 
> summits – and having two summits and one PTG will make things worse. 
> Therefore I propose to scrap the PTG and add “design summits” back to the 
> OpenStack summit. As a side effect this will be a better on-ramp for casual 
> developers who can’t justify going to the PTG and ensure enough developers 
> are on-hand to hear the operator’s feedback.

The original purpose of the summits were for the developers to get together to 
plan what they would work on for the next few months. Over time, the big money 
came pouring in, and they became huge marketing events, with developers pushed 
off to the fringes. The recent PTGs have been refreshing because they are more 
like the original events, where there is no distraction by the corporate 
marketing machines, and we can focus on getting shit done.

My question is: if we only have a release once a year, why do we need two 
Summits a year?

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 and just tag everything monthly, but some projects may
> not be ready to do that and some may want to go more often (libraries
> in particular).

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, based on user surveys, it is only the major 6-month named 
releases that are deployed, and even then, some time after their release.

Integrated releases make sense for deployers. What does it mean if Nova has 
some new stuff, but it requires a new release from Cinder in order to use it, 
and Cinder hasn't yet released the necessary updates? Talking about releasing 
projects on a monthly-tagged basis just dumps the problem of determining what 
works with the rest of the codebase onto the deployers.

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 the
> corner, we lose too much time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.
> 
> As our various components mature, we have less quick-paced feature
> development going on. As more and more people adopt OpenStack, we are
> more careful about not breaking them, which takes additional time. The
> end result is that getting anything done in OpenStack takes more time
> than it used to, but we have kept our cycle rhythm mostly the same.
> 
> Our development pace was also designed for fast development in a time
> where most contributors were full time on OpenStack. But fewer and fewer
> people have 100% of their time to dedicate to OpenStack upstream
> development: a lot of us now have composite jobs or have to participate
> in multiple communities. This is a good thing, and it will only
> accelerate as more and more OpenStack development becomes fueled
> directly by OpenStack operators and users.
> 
> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for coordinated releases as
> soon as possible.
> 
> What it means:
> 
> - We'd only do one *coordinated* release of the OpenStack components per
> year, and maintain one stable branch per year


So I want to zero in on this part of the proposal.

It feels like the major driving factor for frustration with the 6 month cadence
is the weight of the coordinated release versus the value, both for developers
and users.

But, I wonder, why do we put so much emphasis on this one process?

One thing I've always admired about Swift was how immune to the cadence Swift
appears to be.

If a set of enthusiastic developers shows up mid-cycle and starts hammering on
a new feature, there's no angst about whether or not it can be done "this
release". It's worked on, Swift moves forward, and when it is done, Swift
releases.

We have this amazing tool that lets us get away with not doing the hard work
Swift did to encapsulate itself. Zuul has enabled us to test all the projects
that want to co-gate together as one. This allows co-dependencies to creep in
under the covers. We have something that, on first look, appears to be
micro-service-architecture, but then in reality, behaves like a massive
monolithic piece of software.

But maybe we're papering over the real problem. Maybe we need to stop working
so hard to coordinate these releases.

As projects mature, I'd expect some to slow down and some to speed up. Glance,
for instance, is in perpetual maintenance mode. Nova is currently in a pretty
heavy debt pay down state and still landing features. Neutron too. So I'd
expect Glance to make frequent small releases of newly fixed items. Nova might
need to do a slower release while a refactor happens, and then a few follow-ups
to get fixes and small enhancements out.

I understand you mentioned the intermediate release tag and practice. I'm
suggesting that we should focus on getting _everyone_ on that train. I don't
think this works without such an effort.

We can keep the release name cadence. But then we get the best of both worlds.
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 _support it_. Let distros pick those up when they need to ship
new features. Let users jump ahead for a few projects when they need the bug
fixes. And then once a year, have a flag day where we all stop, and make an
assertion that we've done some things, achieved some goals, and suggest that
you upgrade all the components to at least that version, and that we'll make
sure you can do that from the last big version.

I understand the belief that nobody will run the intermediaries. If we don't
make them work independently of other projects, nobody will. But if we do, and
if we make sure our interfaces are solid enough to advance components at a
disjoint pace, then users will in fact start to do just that, and we'll retain
the faster feedback cycle, without the heavy community load of coordinated
releases every 6 months.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

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

2017-12-13 Thread Melvin Hillsman

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 to them and generally reduce stress in OpenStack
>> development. I know people who can spend 100% of their time upstream can
>> cope with our current rhythm. I just observe that we have less and less
>> of those full-time people and need to attract more of the part-time one.
>>
>> If this proposal is not helping developers and making OpenStack
>> development less painful, I don't think we should do it:)
>>
>
> Given I have the luxury of working mostly full time upstream, I've
> obviously got a skewed perspective on this whole discussion.
>
> I am interested in which part time developers are having issues keeping up
> and how, i.e. are these core team members that don't feel they can be good
> core reviewers if they aren't around enough to keep up with the changes
> that are happening? I could definitely see a case like that with some of
> the complicated stuff going on in nova like the placement and cells v2 work.
>
> If we're talking about part time contributors that are contributing bug
> fixes here and there, docs patches, random reviews, I'm not sure how this
> is substantially better for them.
>
> We've said in this thread that project teams are encouraged to still do
> intermediate releases, often. And we're still going to be working on
> features, so how does that help slow things down for the part time
> contributor?
>
> If *everyone* must slow down then that's going to be a problem I think,
> unless we do something like alternating intermediate releases where there
> are new features and then only bug fixes, something like that - up to the
> discretion of each project team as they see fit.
>

This sounds like a path we should consider/discuss more. Are you suggesting
do 1 year but 6 months for new features then next 6 for bug fixes only or
vice versa? Or keep current 6 month cadence and communicate our spring
release is feature rich with ... feature (when the time comes of course),
and our fall release is bug-fix only?


>
> I haven't seen anyone mention this yet either, but if "slowing down"
> begins to look like we're entering maintenance mode, I don't think that's
> going to attract new developers and it's likely to mean long-time key
> maintainers are going to lose interest and start looking elsewhere to
> scratch their itches. It's hard to say what would happen. I can certainly
> keep myself busy with docs patches and bug fixes until the cows come home.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Matt Riedemann


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 spend 100% of their time upstream can
cope with our current rhythm. I just observe that we have less and less
of those full-time people and need to attract more of the part-time one.

If this proposal is not helping developers and making OpenStack
development less painful, I don't think we should do it:)


Given I have the luxury of working mostly full time upstream, I've 
obviously got a skewed perspective on this whole discussion.


I am interested in which part time developers are having issues keeping 
up and how, i.e. are these core team members that don't feel they can be 
good core reviewers if they aren't around enough to keep up with the 
changes that are happening? I could definitely see a case like that with 
some of the complicated stuff going on in nova like the placement and 
cells v2 work.


If we're talking about part time contributors that are contributing bug 
fixes here and there, docs patches, random reviews, I'm not sure how 
this is substantially better for them.


We've said in this thread that project teams are encouraged to still do 
intermediate releases, often. And we're still going to be working on 
features, so how does that help slow things down for the part time 
contributor?


If *everyone* must slow down then that's going to be a problem I think, 
unless we do something like alternating intermediate releases where 
there are new features and then only bug fixes, something like that - up 
to the discretion of each project team as they see fit.


I haven't seen anyone mention this yet either, but if "slowing down" 
begins to look like we're entering maintenance mode, I don't think 
that's going to attract new developers and it's likely to mean long-time 
key maintainers are going to lose interest and start looking elsewhere 
to scratch their itches. It's hard to say what would happen. I can 
certainly keep myself busy with docs patches and bug fixes until the 
cows come home.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Doug Hellmann

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 the adoption
of various versions in production over time, and the number of older
deployments indicated on that chart in April of this year seems to
clearly indicate that users are not adopting releases as quickly
as we are producing them.

[1] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread David Moreau Simard

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 replace the second PTG for teams that need or want to meet
> more often.
>

Are we convinced that the ~3 day formula for the Forum is one we want to
stick with ?
With longer cycles and no PTGs in-between, it actually sounds like a good
opportunity to
revisit the "Forum" events to include the "design" and "ops" summits back
into the event.

Perhaps not in the previous format, because it had its flaws, but with
longer cycles I feel
we need something to close that gap.

I've had a lot of discussions and some people that always went to summits
now no longer
attend neither the PTG (because they don't necessarily contribute upstream)
or the Forum
because it's only three days, costs a lot of money, jet lag, there's little
to no ops/design
exposure.. and the talks end up on YouTube anyway.

> - It doesn't give us LTS. The cost of maintaining branches is not really
> due to the number of them we need to maintain in parallel, it is due to
> the age of the oldest one. We might end up being able to support
> branches for slightly longer as a result of having to maintain less of
> them in parallel, but we will not support our stable branches for a
> significantly longer time as a direct result of this change. The real
> solution here is being discussed by the (still forming) LTS SIG and
> involves having a group step up to continue to maintain some branches
> past EOL.
>

The complaints about the pace of the development and support cycles are
numerous and
I won't repeat them here.

While this is not LTS, I can't help but think this is a compromise or a
middle ground
even though it might not be the intent behind the idea.
Right now we ship a release every 6 months and support each release for 1
year which
means at any given time, there are 3 ongoing "releases", including trunk.

What I'm curious about... is how does this translate into the support cycle
?

- Pike was released 2017-08-30 and the scheduled EOL is 2018-09-03.
- Ocata was released 2017-02-22 and the scheduled EOL is 2018-02-26.

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
one.

2) Keep the support cycle to a year
This would basically mean that as soon as there is a new release, the
previous one would become EOL ? This is what seems suggested here
and I'm really not confident this would be a great idea. It would force
people to upgrade within weeks after a new release to stay on a
supported
version.

As some others have mentioned in the thread, there are pros and cons to
moving to a
year-long cycle and I think it's great that we are having this discussion
as it will help
us make an informed decision.

It won't be possible to please everyone so leaving this up to the technical
committee
to vote on this matter seems fair.

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Matt Riedemann


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 that the pressure is reduced now that
we are past the hype peak...


Yes and no. Nova has tried different tricks in the past like a 
non-priority feature freeze at the 2nd milestone, then we just work on 
the priorities (agreed to at the design summit, when that was a thing) 
in the 3rd milestone. We stopped doing that in Ocata because it was a 
shorter cycle and because of other complications with that process, like 
we'd spend a lot of time in the first milestone doing spec reviews and 
design discussion, then rushing to get non-priority stuff done in the 
second milestone, and then we'd be burned out by the third milestone to 
actually focus on priorities - which is the opposite of what we should 
be doing.


I feel like there is still the normal pressure to please everyone in 
recent releases, that's never going to change, it's never going to be 
"done", but I do feel like we make steady progress and get enough 
non-priority things done at the same time.


I think we'll always have a kind of rush toward the end for the big 
complicated things we're working on, because of unexpected things that 
come up during implementation. That's part of the reason I think moving 
the release out won't help with that unless we can be super disciplined 
as a project about doing intermediate releases, even if we know people 
aren't picking them up, just so that we have a goal/deadline to work 
toward rather than say, "meh, we've got 9 months to crank this out, it 
can wait."


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Arkady.Kanevsky

How about add to our biannual questionnaire how often customer upgrade their 
openstack environment?

-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org] 
Sent: Wednesday, December 13, 2017 4:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] 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 deploy 
>> to prod’ gets longer.
> 
> There is always a rush at the Feature Freeze point in a cycle to get things 
> in, or they will be delayed for 6 months. With the year-long cycle, now 
> anything missing Feature Freeze will be delayed by a year. The long cycle 
> also means that a lot more time will be spent backporting things to the 
> current release, since people won’t be able to wait a whole year for some 
> improvements.
> 
> Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).

Yes, I'll admit I'm struggling with that part of the proposal too. We could use 
intermediary releases but there would always be a "more important" release.

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 that the pressure is reduced now that we are past the hype 
peak...

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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...
> >
> 
> [in which the final stage of the release is 8 weeks, therefore shorter than
> the other 10/11 week stages]
> 
> I'm not going to go on about this beyond this mail, since I've been roundly
> shot down about this before, but please could we have the gap between the
> final milestone and the release, be longer? Every extra week there is more
> release quality :)
> 

I want to believe that is true.

However I have no real evidence that it is.

What class of users runs RC's in OpenStack?

With narrower scoped projects, running RC's is pretty common. If you're a PHP
shop, you might have automated testing setup to test your code with the RC so
you can upgrade sooner. But you might not bother to run RC's of MySQL, because
you're happy with the feature set and comfortable with the amount of time the
release you're running is supported.

However, with OpenStack's "upgrade all the things" approach to coordinated
releases and testing, this becomes a much higher bar for running an RC.

My somewhat educated guess is that our automated CI is about the only thing
beyond a few developers testing their own new features that will run this code
before it is released.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread German Eichberger

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 summit (and in fact I skipped 
Sydney). On the other hand some devs got together and hashed out some plans for 
their projects. Personally, I feel the PTG is not working if we also have 
summits – and having two summits and one PTG will make things worse. Therefore 
I propose to scrap the PTG and add “design summits” back to the OpenStack 
summit. As a side effect this will be a better on-ramp for casual developers 
who can’t justify going to the PTG and ensure enough developers are on-hand to 
hear the operator’s feedback.

German

From: Tim Bell <tim.b...@cern.ch>
Reply-To: "OpenStack Development Mailing 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: [openstack-dev] [all] Switching to longer development cycles

The forums would seem to provide a good opportunity for get togethers during 
the release cycle. With these happening April/May and October/November, there 
could be a good chance for productive team discussions and the opportunities to 
interact with the user/operator community.

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.

If there is consensus, I’d suggest to get feedback from openstack-operators on 
the idea. My initial suspicion is that it would be welcomed, especially by 
those running from distros, but there are many different perspectives.

Tim

From: Amy Marrich <a...@demarco.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, 13 December 2017 at 18:58
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all] Switching to longer development cycles

I think Sean has made some really good points with the PTG setting things off 
in the start of the year and conversations carrying over to the Forums and 
their importance. And having a gap at the end of the year as Jay mentioned will 
give time for those still about to do finishing work if needed and if it's 
planned for in the individual projects they can have an earlier 'end' to allow 
for members not being around.

The one year release would help to get 'new' users to adopt a more recent 
release, even if it's the one from the year previously as there is the 
'confidence' that it's been around for a bit and been used by others in 
production. And if projects want to do incrementals they can, if I've read the 
thread correctly. Also those that want the latest will just use master anyways 
as some do currently.

With the move to a yearly cycle I agree with the 1 year cycle for PTLs, though 
if needed perhaps a way to have a co-PTL or a LT could be implemented to help 
with the longer duties?

My 2 cents from the peanut gallery:)

Amy (spotz)

On Wed, Dec 13, 2017 at 11:29 AM, Sean McGinnis 
<sean.mcgin...@gmx.com<mailto:sean.mcgin...@gmx.com>> wrote:
On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote:
> Hey
>
> On 13 December 2017 at 17:12, Jimmy McArthur 
> <ji...@openstack.org<mailto:ji...@openstack.org>> wrote:
>
> > 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 replace the second PTG for teams that need or want to meet
> >> more often.
> >>
> > The PTG seems to allow greater coordination between groups. I worry that
> > going back to an optional mid-cycle would reduce this cross-collaboration,
> > while also reducing project face-to-face time.
>
>
> I can't speak for the Foundation, but I would think it would be good to
> have an official PTG in the middle of the cycle (perhaps neatly aligned
> with some kind of milestone/event) that lets people discuss plans for
> finishing off the release, and early work they want to get started on for
> the subsequent release). The problem with team-organised midcycles (as I'm
> sure everyone remembers), is that there's little/no opportunity for
> cross-project work.
>
> --
> Cheers,
>
> Chris
This was one of my concerns initially too. We may have to see how things go and
course correct once we have a little more data to go on. But the thought (or at
least the hope) was that we could

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

2017-12-13 Thread Doug Hellmann

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 prod’ gets longer.
> 
> There is always a rush at the Feature Freeze point in a cycle to get things 
> in, or they will be delayed for 6 months. With the year-long cycle, now 
> anything missing Feature Freeze will be delayed by a year. The long cycle 
> also means that a lot more time will be spent backporting things to the 
> current release, since people won’t be able to wait a whole year for some 
> improvements.
> 
> Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).

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 and just tag everything monthly, but some projects may
not be ready to do that and some may want to go more often (libraries
in particular).

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Thierry Carrez

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 the Feature Freeze point in a cycle to get things 
> in, or they will be delayed for 6 months. With the year-long cycle, now 
> anything missing Feature Freeze will be delayed by a year. The long cycle 
> also means that a lot more time will be spent backporting things to the 
> current release, since people won’t be able to wait a whole year for some 
> improvements.
> 
> Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).

Yes, I'll admit I'm struggling with that part of the proposal too. We
could use intermediary releases but there would always be a "more
important" release.

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 that the pressure is reduced now that
we are past the hype peak...

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-12-13 Thread Thierry Carrez

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
> agree it *does* do us some good then we're motivated to work out
> the other details.

Exactly. That's what this proposal is about.

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 spend 100% of their time upstream can
cope with our current rhythm. I just observe that we have less and less
of those full-time people and need to attract more of the part-time one.

If this proposal is not helping developers and making OpenStack
development less painful, I don't think we should do it :)

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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