Re: [openstack-dev] Upstream LTS Releases

Just a thought, cause I have known/do know what Mathieu is talking about and find the disconnect still oddly weird. Why aren't developer people from other companies coming into to where Mathieu works (or where I work) and seeing how it really works down on the ground here. I mean if we still

Re: [openstack-dev] Upstream LTS Releases

Some clarifications below. On Wed, Nov 15, 2017 at 4:52 AM, Bogdan Dobrelya wrote: > Thank you Mathieu for the insights! > >> To add details to what happened: >> * Upgrade was never made a #1 priority. It was a one man show for far >> too long. (myself) > > > I suppose that

Re: [openstack-dev] Upstream LTS Releases

On 14/11/17 15:10 -0500, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: >> The quality of backported fixes is expected to be a direct (and only?) >> interest of those new teams of new cores, coming from

Re: [openstack-dev] Upstream LTS Releases

I suggested by Rocky, I moved the discussion to the -sigs list by posting my promised summary of the session at: http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000148.html Please continue the discussion there, to avoid the cross-posting. If you haven't already, please

Re: [openstack-dev] Upstream LTS Releases

Thank you Mathieu for the insights! To add details to what happened: * Upgrade was never made a #1 priority. It was a one man show for far too long. (myself) I suppose that confirms that upgrades is very nice to have in production deployments, eventually, maybe... (please read below to

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 09:01 PM, Chris Friesen wrote: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and operators and vendors. I'm not assuming bad intentions, not at

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 11:17 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600: On 11/14/2017 02:10 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600: > On 11/14/2017 02:10 PM, Doug Hellmann wrote: > > Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: > >> On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > >> > The quality of backported fixes is expected to

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 02:10 PM, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and

Re: [openstack-dev] Upstream LTS Releases

<openstack-dev@lists.openstack.org>; openstack-oper. operat...@lists.openstack.org> > Subject: Re: [openstack-dev] Upstream LTS Releases > > Hi all - please note this conversation has been split variously across -dev > and - > operators. > > One small observatio

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600: > On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > > >> The quality of backported fixes is expected to be a direct (and only?) > >> interest of those new teams of new cores, coming from users and operators > >> and > >> vendors.

Re: [openstack-dev] Upstream LTS Releases

On Wed, Nov 15, 2017 at 7:01 AM, Chris Friesen wrote: > On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: > >>> The quality of backported fixes is expected to be a direct (and only?) >>> interest of those new teams of new cores, coming from users and operators >>> and >>>

Re: [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 11:25:03AM -0500, Doug Hellmann wrote: > Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100: > > >> The concept, in general, is to create a new set of cores from these > > >> groups, and use 3rd party CI to validate patches. There are lots of > > >>

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 01:28 PM, Dmitry Tantsur wrote: The quality of backported fixes is expected to be a direct (and only?) interest of those new teams of new cores, coming from users and operators and vendors. I'm not assuming bad intentions, not at all. But there is a lot of involved in a decision

Re: [openstack-dev] Upstream LTS Releases

On Tue, Nov 14, 2017 at 11:28 AM, Dmitry Tantsur wrote: > On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote: The concept, in general, is to create a new set of cores from these groups, and use 3rd party CI to validate patches. There are lots of details to be

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 05:08 PM, Bogdan Dobrelya wrote: The concept, in general, is to create a new set of cores from these groups, and use 3rd party CI to validate patches. There are lots of details to be worked out yet, but our amazing UC (User Committee) will be begin working out the details. What

Re: [openstack-dev] Upstream LTS Releases

On 11/14/2017 10:25 AM, Doug Hellmann wrote: Why would we have third-party jobs on an old branch that we don't have on master, for instance? One possible reason is to test the stable version of OpenStack against a stable version of the underlying OS distro. (Where that distro may not meet

Re: [openstack-dev] Upstream LTS Releases

Blair, Please add #2 as a line proposal in: https://etherpad.openstack.org/p/LTS-proposal So far it's focused on #1 Thanks, Dims On Wed, Nov 15, 2017 at 3:30 AM, Blair Bethwaite wrote: > Hi all - please note this conversation has been split variously across > -dev

Re: [openstack-dev] Upstream LTS Releases

Hi all - please note this conversation has been split variously across -dev and -operators. One small observation from the discussion so far is that it seems as though there are two issues being discussed under the one banner: 1) maintain old releases for longer 2) do stable releases less

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Bogdan Dobrelya's message of 2017-11-14 17:08:31 +0100: > >> The concept, in general, is to create a new set of cores from these > >> groups, and use 3rd party CI to validate patches. There are lots of > >> details to be worked out yet, but our amazing UC (User Committee) will > >>

Re: [openstack-dev] Upstream LTS Releases

Bogdan, Team, So i got this etherpad started. Please add policy ideas at the top and volunteer for the team too., https://etherpad.openstack.org/p/LTS-proposal Thanks, Dims On Wed, Nov 15, 2017 at 3:08 AM, Bogdan Dobrelya wrote: >>> The concept, in general, is to create a

Re: [openstack-dev] Upstream LTS Releases

The concept, in general, is to create a new set of cores from these groups, and use 3rd party CI to validate patches. There are lots of details to be worked out yet, but our amazing UC (User Committee) will be begin working out the details. What is the most worrying is the exact "take over"

Re: [openstack-dev] Upstream LTS Releases

On Sun, Nov 12, 2017 at 4:03 AM, Thomas Goirand wrote: > Instead of thinking "this will be more work", why don't you think of the > LTS as an opportunity to only release OpenStack Chef for the LTS? That'd > be a lot less work indeed, and IMO that's a very good opportunity for >

Re: [openstack-dev] Upstream LTS Releases

On 11/08/2017 05:27 PM, Samuel Cassiba wrote: > ie. deployment-focused development > teams already under a crunch as contributor count continues to decline > in favor of other projects inside and out of OpenStack. Did you even think that one of the reason for such a decline, is that OpenStack is

Re: [openstack-dev] Upstream LTS Releases

On Wed, Nov 8, 2017 at 11:17 AM, Doug Hellmann wrote: > Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800: >> On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick >> wrote: >> > Hello Ops folks, >> > >> > This morning at the Sydney

Re: [openstack-dev] Upstream LTS Releases

Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800: > On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick > wrote: > > Hello Ops folks, > > > > This morning at the Sydney Summit we had a very well attended and very > > productive session about how to go

Re: [openstack-dev] Upstream LTS Releases

Hi! This is amazing to see this discussed! Looking forward to more details. On 11/08/2017 12:28 AM, Erik McCormick wrote: Hello Ops folks, This morning at the Sydney Summit we had a very well attended and very productive session about how to go about keeping a selection of past releases

Re: [openstack-dev] Upstream LTS Releases

On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick wrote: > Hello Ops folks, > > This morning at the Sydney Summit we had a very well attended and very > productive session about how to go about keeping a selection of past > releases available and maintained for a longer

Re: [openstack-dev] Upstream LTS Releases

On Nov 8, 2017 1:52 PM, "James E. Blair" wrote: Erik McCormick writes: > On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair wrote: >> Erik McCormick writes: >> >>> The concept, in general, is to

Re: [openstack-dev] Upstream LTS Releases

Erik McCormick writes: > On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair wrote: >> Erik McCormick writes: >> >>> The concept, in general, is to create a new set of cores from these >>> groups, and use 3rd party CI to

Re: [openstack-dev] Upstream LTS Releases

Erik McCormick wrote: > This morning at the Sydney Summit we had a very well attended and very > productive session about how to go about keeping a selection of past > releases available and maintained for a longer period of time (LTS). > > There was agreement in the room that this could be

Re: [openstack-dev] Upstream LTS Releases

On Tue, Nov 7, 2017 at 6:45 PM, James E. Blair wrote: > Erik McCormick writes: > >> The concept, in general, is to create a new set of cores from these >> groups, and use 3rd party CI to validate patches. There are lots of >> details to be worked

Re: [openstack-dev] Upstream LTS Releases

Erik McCormick writes: > The concept, in general, is to create a new set of cores from these > groups, and use 3rd party CI to validate patches. There are lots of > details to be worked out yet, but our amazing UC (User Committee) will > be begin working out the

[openstack-dev] Upstream LTS Releases

Hello Ops folks, This morning at the Sydney Summit we had a very well attended and very productive session about how to go about keeping a selection of past releases available and maintained for a longer period of time (LTS). There was agreement in the room that this could be accomplished by