settingsLogin | Registersettings

Re: [openstack-dev] Upstream LTS Releases

0 votes

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 available and maintained for a longer period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

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" process. Does it mean that
the teams will give away the +2 power to a different team? Or will our (small)
stable teams still be responsible for landing changes? If so, will they have to
learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control over
quality at the same time :) Probably the final proposal will clarify it..

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 15, 2017 in openstack-dev by Dmitry_Tantsur (18,080 points)   2 3 4

39 Responses

0 votes

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
emccormick@cirrusseven.com 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 period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

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.

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik


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

In advance, pardon the defensive tone. I was not in a position to
attend, or even be in Sydney. However, as this comes across the ML, I
can't help but get the impression this effort would be forcing more
work on already stretched teams, 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.

As a friendly reminder, Chef is still actively developed, though we've
not had a great return from recruiting more people. We have about 3.5
active developers, including active cores, and non-cores who felt it
worthwhile to contribute back upstream. There is no major corporate
backer here, but merely a handful of potentially stubborn volunteers.
Nobody is behind the curtain, but Chef OpenStack still have a few
active users (once again, I point to the annual User Survey results)
and contributors. However, we do not use the MLs as a primary
communication means, so I can see how we might be forgotten or
ignored.

In practice, no one likes talking about Chef OpenStack that I've
experienced, neither in the Chef or OpenStack communities. However, as
a maintainer, I keep making it a point to bring it up when it seems
the project gets papered over, or the core team gets signed up for
more work decided in a room half a world away. Admittedly, the whole
deployment method is a hard sell if you're not using Chef in some way.
It has always been my takeaway that the project was merely tolerated
under the OpenStack designation, neither embraced nor even liked, even
being the "official" OpenStack deployment method for a major
deployment toolset. The Foundation's support has been outstanding when
we've needed it, but that's about as far as the delightful goes. The
Chef community is a bit more tolerant of someone using the Chef
moniker for OpenStack, but migrating from Gerrit to GitHub is a major
undertaking that the development team may or may not be able to
reasonably support without more volunteers. Now that the proposition
exists about making a Stable Release liaison derived from existing
cores, I can't help but get the impression that, for active-but-quiet
projects, it'll be yet another PTL responsibility to keep up with, in
addition to the rigors that already come with the role. I'm hoping
I'll be proven wrong here, but I can and do get in trouble for hoping.

There are still a lot of details to work out, so the announcement
of an "agreement" is a bit premature. Rest assured, however, that
the proposed change is not about "requiring," or even asking, anyone
to do any new work that they don't want to do.

In the past, we asked folks who wanted to have old branches maintained
for a long time to join our stable management team with the premise
that if the stable team grew it could support more branches for
longer. We've been repeating that answer for about 5 years now,
without much success, in part because the expertise needed to
actually deal with complex failures of stable branch jobs is not
widely available and gaining the experience is a huge time commitment
that most users can't afford. It should be clear to everyone that
the previous approach isn't working.

The new proposal is meant to empower people who want to do work
to have a place to do it. At the same time, we need to lower the
expectations of what is likely to be produced by recognizing that
the older the branches get the more brittle they will become. We
also want to ensure that any burden created by taking on more work
is absorbed by the people doing the work, and does not unduly impact
the folks not interested in doing it.

With those caveats in mind, the idea is to continue the current
stable policy, more or less as it is, with development teams taking
responsibility for backports within a couple of stable branches.
Then at the point in time that we now call the "end of life" for a
branch, instead of deleting it we would leave it open and establish
a new team of people who want to continue to maintain that
branch
. We anticipate the members of those new teams coming mostly
from users and distributors, based on who are using the release by
deploying it themselves or supporting it for their customers. Not
all branches are going to attract teams to maintain them, and that's
OK.

After the switch from stable to whatever we are calling this new
phase, we will stop tagging releases so that consumers of the branch
have a clear indication that the level of support has changed.
Backports and other fixes can be shared, but to consume them a user
will have to build their own packages.

Regarding testing, my recollection is that we would leave jobs
running as they are, and as they break down the team that maintains
the branch could decide how to deal with them. Fixing the jobs
upstream where possible is preferred, but depending on who is
maintaining the branch, the level of support they are actually
providing, and the nature of the breakage we said that removing
individual tests or whole jobs is another option. The use of
third-party testing came up as another area of flexibility, but is
not required.

Erik and some other folks from the session are going to need to
write up some policy and process change proposals so we can hash
out all of the details and make sure we're all agreeing to what we
think we're agreeing to. Nothing will change until that more complete
discussion happens, so as Thierry said watch for that thread.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 8, 2017 by Doug_Hellmann (87,520 points)   3 4 4
0 votes

On Wed, Nov 8, 2017 at 11:17 AM, Doug Hellmann doug@doughellmann.com 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
emccormick@cirrusseven.com 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 period of time (LTS).

There was agreement in the room that this could be accomplished by
moving the responsibility for those releases from the Stable Branch
team down to those who are already creating and testing patches for
old releases: The distros, deployers, and operators.

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.

Please take a look at the Etherpad from the session if you'd like to
see the details. More importantly, if you would like to contribute to
this effort, please add your name to the list starting on line 133.

https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases

Thanks to everyone who participated!

Cheers,
Erik


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

In advance, pardon the defensive tone. I was not in a position to
attend, or even be in Sydney. However, as this comes across the ML, I
can't help but get the impression this effort would be forcing more
work on already stretched teams, 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.

As a friendly reminder, Chef is still actively developed, though we've
not had a great return from recruiting more people. We have about 3.5
active developers, including active cores, and non-cores who felt it
worthwhile to contribute back upstream. There is no major corporate
backer here, but merely a handful of potentially stubborn volunteers.
Nobody is behind the curtain, but Chef OpenStack still have a few
active users (once again, I point to the annual User Survey results)
and contributors. However, we do not use the MLs as a primary
communication means, so I can see how we might be forgotten or
ignored.

In practice, no one likes talking about Chef OpenStack that I've
experienced, neither in the Chef or OpenStack communities. However, as
a maintainer, I keep making it a point to bring it up when it seems
the project gets papered over, or the core team gets signed up for
more work decided in a room half a world away. Admittedly, the whole
deployment method is a hard sell if you're not using Chef in some way.
It has always been my takeaway that the project was merely tolerated
under the OpenStack designation, neither embraced nor even liked, even
being the "official" OpenStack deployment method for a major
deployment toolset. The Foundation's support has been outstanding when
we've needed it, but that's about as far as the delightful goes. The
Chef community is a bit more tolerant of someone using the Chef
moniker for OpenStack, but migrating from Gerrit to GitHub is a major
undertaking that the development team may or may not be able to
reasonably support without more volunteers. Now that the proposition
exists about making a Stable Release liaison derived from existing
cores, I can't help but get the impression that, for active-but-quiet
projects, it'll be yet another PTL responsibility to keep up with, in
addition to the rigors that already come with the role. I'm hoping
I'll be proven wrong here, but I can and do get in trouble for hoping.

There are still a lot of details to work out, so the announcement
of an "agreement" is a bit premature. Rest assured, however, that
the proposed change is not about "requiring," or even asking, anyone
to do any new work that they don't want to do.

In the past, we asked folks who wanted to have old branches maintained
for a long time to join our stable management team with the premise
that if the stable team grew it could support more branches for
longer. We've been repeating that answer for about 5 years now,
without much success, in part because the expertise needed to
actually deal with complex failures of stable branch jobs is not
widely available and gaining the experience is a huge time commitment
that most users can't afford. It should be clear to everyone that
the previous approach isn't working.

As a three-time PTL for a dead-no-alive-no-dead-maybe-undead-no-alive
open source project, I feel the pain first-hand. I would love to
support Mitaka and cherry-pick changes from Ocata, Pike or Queens, but
today I cannot. I've resorted to begging for anything that helps keep
the project moving forward that I cannot do myself, due to timing or
otherwise.

The new proposal is meant to empower people who want to do work
to have a place to do it. At the same time, we need to lower the
expectations of what is likely to be produced by recognizing that
the older the branches get the more brittle they will become. We
also want to ensure that any burden created by taking on more work
is absorbed by the people doing the work, and does not unduly impact
the folks not interested in doing it.

With those caveats in mind, the idea is to continue the current
stable policy, more or less as it is, with development teams taking
responsibility for backports within a couple of stable branches.
Then at the point in time that we now call the "end of life" for a
branch, instead of deleting it we would leave it open and establish
a new team of people who want to continue to maintain that
branch
. We anticipate the members of those new teams coming mostly
from users and distributors, based on who are using the release by
deploying it themselves or supporting it for their customers. Not
all branches are going to attract teams to maintain them, and that's
OK.

Leaving the branch open for future development is OK with me. I've had
instances in which the codebase was still fresh enough to deliver bug
fixes, but it was against a release marked "End of Lifecycle", and
thus the bug stamped with a happy little WONTFIX. The battered and
beaten support agent I keep locked in my attic is deeply saddened by
these cases when I mention them.

After the switch from stable to whatever we are calling this new
phase, we will stop tagging releases so that consumers of the branch
have a clear indication that the level of support has changed.
Backports and other fixes can be shared, but to consume them a user
will have to build their own packages.

Regarding testing, my recollection is that we would leave jobs
running as they are, and as they break down the team that maintains
the branch could decide how to deal with them. Fixing the jobs
upstream where possible is preferred, but depending on who is
maintaining the branch, the level of support they are actually
providing, and the nature of the breakage we said that removing
individual tests or whole jobs is another option. The use of
third-party testing came up as another area of flexibility, but is
not required.

At some point, someone will have to say enough's enough, though, but
who makes that call? In Chefland, chef-client grows a new major
release every eight or so months, with a supported lifecycle of N-1,
so it wouldn't be nearly as straightforward as just leaving the branch
open just because someone is willing to own the changes and make sure
the gates still fired. The rest of the ecosystem can decay to a state
of unuse for a given release, as well, due to flipped solar flares and
good old bitrot.

Erik and some other folks from the session are going to need to
write up some policy and process change proposals so we can hash
out all of the details and make sure we're all agreeing to what we
think we're agreeing to. Nothing will change until that more complete
discussion happens, so as Thierry said watch for that thread.

Doug


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

This is a topic of definite interest to me, so I'll keep an eye out to
see what unfolds. Threads don't get tagged with [chef] anymore, and
I'm not in Sydney, so I have to wade through the firehose to even
catch these types of changes before they become reality.

--
Best,
Samuel Cassiba


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 9, 2017 by s_at_cassiba.com (1,200 points)  
0 votes

On Sun, Nov 12, 2017 at 4:03 AM, Thomas Goirand zigo@debian.org 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
you to scale down.

+1000

Having worked downstream, I've personally spent far too much time on
forked stable branches trying to keep them in a sane/healthy state.
Our current model just encourages all of that work to happen
downstream in the dark in varying divergent ways. Even if a minor
fraction from each downstream team is freed to interact upstream, that
will help all of us working upstream regardless of what organization
we come from.

We should also keep in mind that this does present the opportunity for
an improved feedback loop. If we have an LTS branch that we receive a
huge patch on, that is an opportunity to reflect on why, and ask "What
did we miss or not understand originally?"

-Julia


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 12, 2017 by Julia_Kreger (1,460 points)   3
0 votes

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 bdobreli@redhat.com 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 is the most worrying is the exact "take over" process. Does it mean
that the teams will give away the +2 power to a different team? Or will our
(small) stable teams still be responsible for landing changes? If so, will
they have to learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control
over quality at the same time :) Probably the final proposal will clarify
it..

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. The more parties to establish their 3rd party checking jobs,
the better proposed changes communicated, which directly affects the quality
in the end. I also suppose, contributors from ops world will likely be only
struggling to see things getting fixed, and not new features adopted by
legacy deployments they're used to maintain. So in theory, this works and as
a mainstream developer and maintainer, you need no to fear of losing control
over LTS code :)

Another question is how to not block all on each over, and not push
contributors away when things are getting awry, jobs failing and merging is
blocked for a long time, or there is no consensus reached in a code review.
I propose the LTS policy to enforce CI jobs be non-voting, as a first step
on that way, and giving every LTS team member a core rights maybe? Not sure
if that works though.

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando


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

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by Davanum_Srinivas (35,920 points)   2 4 6
0 votes

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" process. Does it mean that
the teams will give away the +2 power to a different team? Or will our (small)
stable teams still be responsible for landing changes? If so, will they have to
learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control over
quality at the same time :) Probably the final proposal will clarify it..

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. The more parties to establish their 3rd party
checking jobs, the better proposed changes communicated, which directly
affects the quality in the end. I also suppose, contributors from ops
world will likely be only struggling to see things getting fixed, and
not new features adopted by legacy deployments they're used to maintain.
So in theory, this works and as a mainstream developer and maintainer,
you need no to fear of losing control over LTS code :)

Another question is how to not block all on each over, and not push
contributors away when things are getting awry, jobs failing and merging
is blocked for a long time, or there is no consensus reached in a code
review. I propose the LTS policy to enforce CI jobs be non-voting, as a
first step on that way, and giving every LTS team member a core rights
maybe? Not sure if that works though.

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by bdobreli_at_redhat.c (2,260 points)   1 2
0 votes

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
be begin working out the details.

What is the most worrying is the exact "take over" process. Does it mean that
the teams will give away the +2 power to a different team? Or will our (small)
stable teams still be responsible for landing changes? If so, will they have to
learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control over
quality at the same time :) Probably the final proposal will clarify it..

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. The more parties to establish their 3rd party

We have an unhealthy focus on "3rd party" jobs in this discussion. We
should not assume that they are needed or will be present. They may be,
but we shouldn't build policy around the assumption that they will. Why
would we have third-party jobs on an old branch that we don't have on
master, for instance?

checking jobs, the better proposed changes communicated, which directly
affects the quality in the end. I also suppose, contributors from ops
world will likely be only struggling to see things getting fixed, and
not new features adopted by legacy deployments they're used to maintain.
So in theory, this works and as a mainstream developer and maintainer,
you need no to fear of losing control over LTS code :)

Another question is how to not block all on each over, and not push
contributors away when things are getting awry, jobs failing and merging
is blocked for a long time, or there is no consensus reached in a code
review. I propose the LTS policy to enforce CI jobs be non-voting, as a
first step on that way, and giving every LTS team member a core rights
maybe? Not sure if that works though.

I'm not sure what change you're proposing for CI jobs and their voting
status. Do you mean we should make the jobs non-voting as soon as the
branch passes out of the stable support period?

Regarding the review team, anyone on the review team for a branch
that goes out of stable support will need to have +2 rights in that
branch. Otherwise there's no point in saying that they're maintaining
the branch.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by Doug_Hellmann (87,520 points)   3 4 4
0 votes

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 frequently

It would be interesting to understand if the people who want longer
maintenance windows would be helped by #2.

On 14 November 2017 at 09:25, Doug Hellmann doug@doughellmann.com 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
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" process. Does it mean that
the teams will give away the +2 power to a different team? Or will our (small)
stable teams still be responsible for landing changes? If so, will they have to
learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control over
quality at the same time :) Probably the final proposal will clarify it..

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. The more parties to establish their 3rd party

We have an unhealthy focus on "3rd party" jobs in this discussion. We
should not assume that they are needed or will be present. They may be,
but we shouldn't build policy around the assumption that they will. Why
would we have third-party jobs on an old branch that we don't have on
master, for instance?

checking jobs, the better proposed changes communicated, which directly
affects the quality in the end. I also suppose, contributors from ops
world will likely be only struggling to see things getting fixed, and
not new features adopted by legacy deployments they're used to maintain.
So in theory, this works and as a mainstream developer and maintainer,
you need no to fear of losing control over LTS code :)

Another question is how to not block all on each over, and not push
contributors away when things are getting awry, jobs failing and merging
is blocked for a long time, or there is no consensus reached in a code
review. I propose the LTS policy to enforce CI jobs be non-voting, as a
first step on that way, and giving every LTS team member a core rights
maybe? Not sure if that works though.

I'm not sure what change you're proposing for CI jobs and their voting
status. Do you mean we should make the jobs non-voting as soon as the
branch passes out of the stable support period?

Regarding the review team, anyone on the review team for a branch
that goes out of stable support will need to have +2 rights in that
branch. Otherwise there's no point in saying that they're maintaining
the branch.

Doug


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

--
Cheers,
~Blairo


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by Blair_Bethwaite (4,080 points)   3 4
0 votes

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
blair.bethwaite@gmail.com wrote:
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 frequently

It would be interesting to understand if the people who want longer
maintenance windows would be helped by #2.

On 14 November 2017 at 09:25, Doug Hellmann doug@doughellmann.com 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
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" process. Does it mean that
the teams will give away the +2 power to a different team? Or will our (small)
stable teams still be responsible for landing changes? If so, will they have to
learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control over
quality at the same time :) Probably the final proposal will clarify it..

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. The more parties to establish their 3rd party

We have an unhealthy focus on "3rd party" jobs in this discussion. We
should not assume that they are needed or will be present. They may be,
but we shouldn't build policy around the assumption that they will. Why
would we have third-party jobs on an old branch that we don't have on
master, for instance?

checking jobs, the better proposed changes communicated, which directly
affects the quality in the end. I also suppose, contributors from ops
world will likely be only struggling to see things getting fixed, and
not new features adopted by legacy deployments they're used to maintain.
So in theory, this works and as a mainstream developer and maintainer,
you need no to fear of losing control over LTS code :)

Another question is how to not block all on each over, and not push
contributors away when things are getting awry, jobs failing and merging
is blocked for a long time, or there is no consensus reached in a code
review. I propose the LTS policy to enforce CI jobs be non-voting, as a
first step on that way, and giving every LTS team member a core rights
maybe? Not sure if that works though.

I'm not sure what change you're proposing for CI jobs and their voting
status. Do you mean we should make the jobs non-voting as soon as the
branch passes out of the stable support period?

Regarding the review team, anyone on the review team for a branch
that goes out of stable support will need to have +2 rights in that
branch. Otherwise there's no point in saying that they're maintaining
the branch.

Doug


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

--
Cheers,
~Blairo


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

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by Davanum_Srinivas (35,920 points)   2 4 6
0 votes

On Tue, Nov 14, 2017 at 11:30 AM, Blair Bethwaite
blair.bethwaite@gmail.com wrote:
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 frequently

It would be interesting to understand if the people who want longer
maintenance windows would be helped by #2.

I would like to hear from people who do not want #2 and why not.
What are the benefits of 6 months vs. 1 year? I have heard objections
in the hallway track, but I have struggled to retain the rationale for
more than 10 seconds. I think this may be more of a religious
discussion that could take a while though.

1 is something we can act on right now with the eventual goal of

being able to skip releases entirely. We are addressing the
maintenance of the old issue right now. As we get farther down the
road of fast-forward upgrade tooling, then we will be able to please
those wishing for a slower upgrade cadence, and those that want to
stay on the bleeding edge simultaneously.

-Erik

On 14 November 2017 at 09:25, Doug Hellmann doug@doughellmann.com 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
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" process. Does it mean that
the teams will give away the +2 power to a different team? Or will our (small)
stable teams still be responsible for landing changes? If so, will they have to
learn how to debug 3rd party CI jobs?

Generally, I'm scared of both overloading the teams and losing the control over
quality at the same time :) Probably the final proposal will clarify it..

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. The more parties to establish their 3rd party

We have an unhealthy focus on "3rd party" jobs in this discussion. We
should not assume that they are needed or will be present. They may be,
but we shouldn't build policy around the assumption that they will. Why
would we have third-party jobs on an old branch that we don't have on
master, for instance?

checking jobs, the better proposed changes communicated, which directly
affects the quality in the end. I also suppose, contributors from ops
world will likely be only struggling to see things getting fixed, and
not new features adopted by legacy deployments they're used to maintain.
So in theory, this works and as a mainstream developer and maintainer,
you need no to fear of losing control over LTS code :)

Another question is how to not block all on each over, and not push
contributors away when things are getting awry, jobs failing and merging
is blocked for a long time, or there is no consensus reached in a code
review. I propose the LTS policy to enforce CI jobs be non-voting, as a
first step on that way, and giving every LTS team member a core rights
maybe? Not sure if that works though.

I'm not sure what change you're proposing for CI jobs and their voting
status. Do you mean we should make the jobs non-voting as soon as the
branch passes out of the stable support period?

Regarding the review team, anyone on the review team for a branch
that goes out of stable support will need to have +2 rights in that
branch. Otherwise there's no point in saying that they're maintaining
the branch.

Doug


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

--
Cheers,
~Blairo


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by Erik_McCormick (3,880 points)   2 3
0 votes

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 the
package version requirements for running master.)

Chris


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by Chris_Friesen (20,420 points)   2 11 18
...