settingsLogin | Registersettings

[openstack-dev] [all] [stable] No longer doing stable point releases

0 votes

Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt the
work of the team in a "big tent" world.

One of the key questions there was whether we should continue doing
stable point releases. Those were basically tags with the same version
number ("2015.1.1") that we would periodically push to the stable
branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some projects
(like Swift) were not part of the "stable point releases". More and more
projects are considering issuing intermediary releases (like Swift
does), like Ironic. That would result in a variety of version numbers,
and ultimately less and less projects being able to have a common
"2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very small
team of volunteers, especially with projects caring about stable
branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping them
working.

(3) The resulting "stable point releases" are mostly useless. Stable
branches are supposed to be always usable, and the "released" version
did not undergo significantly more testing. Issuing them actually
discourages people from taking whatever point in stable branches makes
the most sense for them, testing and deploying that.

The suggestion we made during that session (and which was approved by
the session participants) is therefore to just get rid of the "stable
point release" concept altogether for non-libraries. That said:

  • we'd still do individual point releases for libraries (for critical
    bugs and security issues), so that you can still depend on a specific
    version there

  • we'd still very much maintain stable branches (and actually focus our
    efforts on that work) to ensure they are a continuous source of safe
    upgrades for users of a given series

Now we realize that the cross-section of our community which was present
in that session might not fully represent the consumers of those
artifacts, which is why we expand the discussion on this mailing-list
(and soon on the operators ML).

If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

--
Thierry Carrez (ttx)


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 May 29, 2015 in openstack-dev by Thierry_Carrez (57,480 points)   3 8 13

116 Responses

0 votes

On 5/29/2015 8:41 AM, Thierry Carrez wrote:
Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt the
work of the team in a "big tent" world.

One of the key questions there was whether we should continue doing
stable point releases. Those were basically tags with the same version
number ("2015.1.1") that we would periodically push to the stable
branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some projects
(like Swift) were not part of the "stable point releases". More and more
projects are considering issuing intermediary releases (like Swift
does), like Ironic. That would result in a variety of version numbers,
and ultimately less and less projects being able to have a common
"2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very small
team of volunteers, especially with projects caring about stable
branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping them
working.

(3) The resulting "stable point releases" are mostly useless. Stable
branches are supposed to be always usable, and the "released" version
did not undergo significantly more testing. Issuing them actually
discourages people from taking whatever point in stable branches makes
the most sense for them, testing and deploying that.

The suggestion we made during that session (and which was approved by
the session participants) is therefore to just get rid of the "stable
point release" concept altogether for non-libraries. That said:

  • we'd still do individual point releases for libraries (for critical
    bugs and security issues), so that you can still depend on a specific
    version there

  • we'd still very much maintain stable branches (and actually focus our
    efforts on that work) to ensure they are a continuous source of safe
    upgrades for users of a given series

Now we realize that the cross-section of our community which was present
in that session might not fully represent the consumers of those
artifacts, which is why we expand the discussion on this mailing-list
(and soon on the operators ML).

If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

To reiterate what I said in the session, for my team personally (IBM),
we don't align with the point release schedules on stable anyway, we
release our own stable release fix packs as needed on our own schedules,
so in that regard I don't see a point in the stable point releases -
especially since most of the time I don't know when those are going to
be anyway so we can't plan for them accurately.

Having said that, what I mentioned in IRC the other day is the one
upside I see to the point releases is it is a milestone that requires
focus from the stable maintainers, which means if stable has been broken
for a few weeks and no one has really noticed, converging on a stable
point release at least forces attention there.

I don't think that is a very good argument for keeping stable point
releases though, since as you said we don't do any additional testing
above and beyond what normally happens in the Jenkins runs. Some of the
distributions might have extra regression testing scenarios, I'm not
sure, but no one really spoke to that in the session from the distros
that were present - I assume they do, but they can do that on their own
schedule anyway IMO.

I am a bit cynical about thinking that dropping point releases will make
people spend more time on caring about the health of the stable branches
(persistent gate failures) or stale changes out for review. I combed
through a lot of open stable/icehouse changes yesterday and there were
many that should have been abandoned 6 months ago but were just sitting
there, and others that were good fixes to have and should have been
merged by now.

Personally I've been trying to point out some of these in the

openstack-stable IRC channel when I see them so that we don't wait so

long on these that they fall into a stable support phase where we don't
think they are appropriate for merging anymore, but if we had acted
sooner they'd be in.

But I'm also the new guy on the team so I've got belly fire, feel free
to tell me to shut up. :)

--

Thanks,

Matt Riedemann


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 May 29, 2015 by Matt_Riedemann (48,320 points)   3 7 20
0 votes

On 05/29/2015 09:44 AM, Matt Riedemann wrote:

On 5/29/2015 8:41 AM, Thierry Carrez wrote:

Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt the
work of the team in a "big tent" world.

One of the key questions there was whether we should continue doing
stable point releases. Those were basically tags with the same version
number ("2015.1.1") that we would periodically push to the stable
branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some projects
(like Swift) were not part of the "stable point releases". More and more
projects are considering issuing intermediary releases (like Swift
does), like Ironic. That would result in a variety of version numbers,
and ultimately less and less projects being able to have a common
"2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very small
team of volunteers, especially with projects caring about stable
branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping them
working.

(3) The resulting "stable point releases" are mostly useless. Stable
branches are supposed to be always usable, and the "released" version
did not undergo significantly more testing. Issuing them actually
discourages people from taking whatever point in stable branches makes
the most sense for them, testing and deploying that.

The suggestion we made during that session (and which was approved by
the session participants) is therefore to just get rid of the "stable
point release" concept altogether for non-libraries. That said:

  • we'd still do individual point releases for libraries (for critical
    bugs and security issues), so that you can still depend on a specific
    version there

  • we'd still very much maintain stable branches (and actually focus our
    efforts on that work) to ensure they are a continuous source of safe
    upgrades for users of a given series

Now we realize that the cross-section of our community which was present
in that session might not fully represent the consumers of those
artifacts, which is why we expand the discussion on this mailing-list
(and soon on the operators ML).

If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

To reiterate what I said in the session, for my team personally (IBM),
we don't align with the point release schedules on stable anyway, we
release our own stable release fix packs as needed on our own schedules,
so in that regard I don't see a point in the stable point releases -
especially since most of the time I don't know when those are going to
be anyway so we can't plan for them accurately.

Having said that, what I mentioned in IRC the other day is the one
upside I see to the point releases is it is a milestone that requires
focus from the stable maintainers, which means if stable has been broken
for a few weeks and no one has really noticed, converging on a stable
point release at least forces attention there.

I don't think that is a very good argument for keeping stable point
releases though, since as you said we don't do any additional testing
above and beyond what normally happens in the Jenkins runs. Some of the
distributions might have extra regression testing scenarios, I'm not
sure, but no one really spoke to that in the session from the distros
that were present - I assume they do, but they can do that on their own
schedule anyway IMO.

I am a bit cynical about thinking that dropping point releases will make
people spend more time on caring about the health of the stable branches
(persistent gate failures) or stale changes out for review. I combed
through a lot of open stable/icehouse changes yesterday and there were
many that should have been abandoned 6 months ago but were just sitting
there, and others that were good fixes to have and should have been
merged by now.

Personally I've been trying to point out some of these in the

openstack-stable IRC channel when I see them so that we don't wait so

long on these that they fall into a stable support phase where we don't
think they are appropriate for merging anymore, but if we had acted
sooner they'd be in.

But I'm also the new guy on the team so I've got belly fire, feel free
to tell me to shut up. :)

I generally agree with the points you just made. From our perspective
(Gentoo) the point releases are nice if only because they require more
focus and testing to be done to be sure they are valid.

That said, I do try to tell our users to use the git based ebuilds (they
point to the stable branches) if at all possible.

--
-- Matthew Thode (prometheanfire)


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 May 29, 2015 by prometheanfire_at_ge (6,880 points)   1 4 5
0 votes

On Fri, May 29, 2015 at 7:41 AM, Thierry Carrez thierry@openstack.org
wrote:

If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
time.

If vendor packages are used (as many folks do) they will need to weigh in
before operators can really give valid feedback.
I've already heard from one vendor that they will continue to do
"point-like" releases that they will support, but we probably need a more
complete answer.

Another issue, operators pulling from stable will just need to do a bit
more diligence themselves (and this is probably appropriate.) One thing we
will do in this diligence is something of tracking rate of new bugs and
looking for windows of opportunity where there may be semi-quiescence.

The other issue I'm aware of is that there will essentially be no "syncing"
across projects (except by the vendors). Operators using upstream will need
to do a better job (ie, more burden) in making sure all of the packages
work together.)


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 May 29, 2015 by David_Medberry (8,000 points)   1 4 5
0 votes

On 29/05/15 14:41, Thierry Carrez wrote:
Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
[...]

I initially misunderstood your email as saying there will no longer be
releases at all... but I see now that you are only talking about
YYYY.X.N with N >= 1, and that we will continue to have YYYY.X.0. Right?

Will the main releases continue to be tagged as YYYY.X.0 ?

Thanks,
Neil


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 May 29, 2015 by Neil_Jerram (8,580 points)   1 4 11
0 votes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

What about release notes? How can we now communicate some changes that
require operator consideration or action?

Ihar

On 05/29/2015 03:41 PM, Thierry Carrez wrote:
Hi everyone,

TL;DR: - We propose to stop tagging coordinated point releases
(like 2015.1.1) - We continue maintaining stable branches as a
trusted source of stable updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt
the work of the team in a "big tent" world.

One of the key questions there was whether we should continue
doing stable point releases. Those were basically tags with the
same version number ("2015.1.1") that we would periodically push to
the stable branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some
projects (like Swift) were not part of the "stable point releases".
More and more projects are considering issuing intermediary
releases (like Swift does), like Ironic. That would result in a
variety of version numbers, and ultimately less and less projects
being able to have a common "2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very
small team of volunteers, especially with projects caring about
stable branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping
them working.

(3) The resulting "stable point releases" are mostly useless.
Stable branches are supposed to be always usable, and the
"released" version did not undergo significantly more testing.
Issuing them actually discourages people from taking whatever point
in stable branches makes the most sense for them, testing and
deploying that.

The suggestion we made during that session (and which was approved
by the session participants) is therefore to just get rid of the
"stable point release" concept altogether for non-libraries. That
said:

  • we'd still do individual point releases for libraries (for
    critical bugs and security issues), so that you can still depend on
    a specific version there

  • we'd still very much maintain stable branches (and actually focus
    our efforts on that work) to ensure they are a continuous source of
    safe upgrades for users of a given series

Now we realize that the cross-section of our community which was
present in that session might not fully represent the consumers of
those artifacts, which is why we expand the discussion on this
mailing-list (and soon on the operators ML).

If you were a consumer of those and will miss them, please explain
why. In particular, please let us know how consuming that version
(which was only made available every n months) is significantly
better than picking your preferred time and get all the current
stable branch HEADs at that time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVaIMzAAoJEC5aWaUY1u57/iIIANPync0FRB0Pe77fBWXEuCqX
jUdoRmhQR3kzGar5UYUXAh5wa2RD/xT1JIlrwjaz4I0jKKGs7nQJ2RoTG68OtgXf
Dk3WzVg7GgmJXrzFim1cACIzDmrX704gegfCSmf8qd0WC03AT3gI/uSR0NYmiW75
xBWSltPPt1T0PaKgV9lLQ6kyCjzdUySve4815jtGPf1hZUpyQlw1+7NE9LEUfbw8
P+wLCB4UyIQ00Hjf90pnjVOT6bhMQ2/2ldoPZsDTCI5PWB52Mqk9ZteuC/1QLBkS
OSRD4fZSMeGDXkSTpIKStZm3J36cM9BGsFzC2OcZ+C52yE3vS4g7cBFaPlLub6k=
=tP/b
-----END PGP SIGNATURE-----


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 May 29, 2015 by Ihar_Hrachyshka (35,300 points)   3 9 16
0 votes

Neil Jerram wrote:

On 29/05/15 14:41, Thierry Carrez wrote:

Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
[...]

I initially misunderstood your email as saying there will no longer be
releases at all... but I see now that you are only talking about
YYYY.X.N with N >= 1, and that we will continue to have YYYY.X.0. Right?

Yes.

Will the main releases continue to be tagged as YYYY.X.0 ?

That is an orthogonal topic, which warrants its own thread, but we also
discussed that in Vancouver. The general idea there is that since we'll
more and more Swift-like things with their own version, the value of
common release versioning for the rest of them becomes questionable.
What we need is a convenient way of telling which version number is the
"kilo" release for each project that aligns with the 6-month cycle.

--
Thierry Carrez (ttx)


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 May 29, 2015 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
What about release notes? How can we now communicate some changes that
require operator consideration or action?

Ihar

On 05/29/2015 03:41 PM, Thierry Carrez wrote:

Hi everyone,

TL;DR: - We propose to stop tagging coordinated point releases
(like 2015.1.1) - We continue maintaining stable branches as a
trusted source of stable updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt
the work of the team in a "big tent" world.

One of the key questions there was whether we should continue
doing stable point releases. Those were basically tags with the
same version number ("2015.1.1") that we would periodically push to
the stable branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some
projects (like Swift) were not part of the "stable point releases".
More and more projects are considering issuing intermediary
releases (like Swift does), like Ironic. That would result in a
variety of version numbers, and ultimately less and less projects
being able to have a common "2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very
small team of volunteers, especially with projects caring about
stable branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping
them working.

(3) The resulting "stable point releases" are mostly useless.
Stable branches are supposed to be always usable, and the
"released" version did not undergo significantly more testing.
Issuing them actually discourages people from taking whatever point
in stable branches makes the most sense for them, testing and
deploying that.

The suggestion we made during that session (and which was approved
by the session participants) is therefore to just get rid of the
"stable point release" concept altogether for non-libraries. That
said:

  • we'd still do individual point releases for libraries (for
    critical bugs and security issues), so that you can still depend on
    a specific version there

  • we'd still very much maintain stable branches (and actually focus
    our efforts on that work) to ensure they are a continuous source of
    safe upgrades for users of a given series

Now we realize that the cross-section of our community which was
present in that session might not fully represent the consumers of
those artifacts, which is why we expand the discussion on this
mailing-list (and soon on the operators ML).

If you were a consumer of those and will miss them, please explain
why. In particular, please let us know how consuming that version
(which was only made available every n months) is significantly
better than picking your preferred time and get all the current
stable branch HEADs at that time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch


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

for release notes just do git log between commit hashes?

--
-- Matthew Thode (prometheanfire)


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 May 29, 2015 by prometheanfire_at_ge (6,880 points)   1 4 5
0 votes

Ihar Hrachyshka wrote:
What about release notes? How can we now communicate some changes that
require operator consideration or action?

Arguably each and every "change requiring operator consideration or
action" mentioned in these release notes is a failure in the stable
branch process -- this branch is supposedly safe to draw updates from.
We should at the very least work to eliminate most of them.

I guess we'd replace those discrete release notes by continuous notes
(like a wiki page for each stable branch), that downstream users could
consult whenever they want to draw from the branch.

--
Thierry Carrez (ttx)


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 May 29, 2015 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On 29 May 2015 at 14:41, Thierry Carrez thierry@openstack.org wrote:
Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt the
work of the team in a "big tent" world.

One of the key questions there was whether we should continue doing
stable point releases. Those were basically tags with the same version
number ("2015.1.1") that we would periodically push to the stable
branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some projects
(like Swift) were not part of the "stable point releases". More and more
projects are considering issuing intermediary releases (like Swift
does), like Ironic. That would result in a variety of version numbers,
and ultimately less and less projects being able to have a common
"2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very small
team of volunteers, especially with projects caring about stable
branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping them
working.

(3) The resulting "stable point releases" are mostly useless. Stable
branches are supposed to be always usable, and the "released" version
did not undergo significantly more testing. Issuing them actually
discourages people from taking whatever point in stable branches makes
the most sense for them, testing and deploying that.

The suggestion we made during that session (and which was approved by
the session participants) is therefore to just get rid of the "stable
point release" concept altogether for non-libraries. That said:

  • we'd still do individual point releases for libraries (for critical
    bugs and security issues), so that you can still depend on a specific
    version there

  • we'd still very much maintain stable branches (and actually focus our
    efforts on that work) to ensure they are a continuous source of safe
    upgrades for users of a given series

Now we realize that the cross-section of our community which was present
in that session might not fully represent the consumers of those
artifacts, which is why we expand the discussion on this mailing-list
(and soon on the operators ML).

If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

--
Thierry Carrez (ttx)

This is generally my opinion as-well, I always hoped that every
commit would be considered a release rather than an arbitrary tagged
date. This empowers vendors and distributors to create their own
service pack style update on a cadence that suits their requirements
and users, rather than feeling tied to cross-vendor schedule or
feeling bad picking interim commits.

The primary push back on this when we started the stable branches was
a vendor wanting to have known release versions for their customers,
and I don't think we have had comment from that (or all) vendors. I
hope this is seen as a positive thing, as it really is IMO.

I have a question about still having library releases you mentioned,
as generally - everything in python is a library. I don't think we
have a definition of what in OpenStack is considered a mere library,
compared to a project that wouldn't have a release.

I also wondered if it might make sense for us to do a better job of
storing metadata of what the shasums of projects used to pass gate for
a given commit - as this might be both useful as a "known good state"
but also, slightly unrelated, might be helpful in debugging gate
blockages in the future.

Thanks

--
Kind Regards,
Dave Walker


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 May 29, 2015 by Dave_Walker (3,660 points)   1 4
0 votes

On 5/29/2015 10:30 AM, Dave Walker wrote:
On 29 May 2015 at 14:41, Thierry Carrez thierry@openstack.org wrote:

Hi everyone,

TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though

Long version:

At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt the
work of the team in a "big tent" world.

One of the key questions there was whether we should continue doing
stable point releases. Those were basically tags with the same version
number ("2015.1.1") that we would periodically push to the stable
branches for all projects.

Those create three problems.

(1) Projects do not all follow the same versioning, so some projects
(like Swift) were not part of the "stable point releases". More and more
projects are considering issuing intermediary releases (like Swift
does), like Ironic. That would result in a variety of version numbers,
and ultimately less and less projects being able to have a common
"2015.1.1"-like version.

(2) Producing those costs a non-trivial amount of effort on a very small
team of volunteers, especially with projects caring about stable
branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping them
working.

(3) The resulting "stable point releases" are mostly useless. Stable
branches are supposed to be always usable, and the "released" version
did not undergo significantly more testing. Issuing them actually
discourages people from taking whatever point in stable branches makes
the most sense for them, testing and deploying that.

The suggestion we made during that session (and which was approved by
the session participants) is therefore to just get rid of the "stable
point release" concept altogether for non-libraries. That said:

  • we'd still do individual point releases for libraries (for critical
    bugs and security issues), so that you can still depend on a specific
    version there

  • we'd still very much maintain stable branches (and actually focus our
    efforts on that work) to ensure they are a continuous source of safe
    upgrades for users of a given series

Now we realize that the cross-section of our community which was present
in that session might not fully represent the consumers of those
artifacts, which is why we expand the discussion on this mailing-list
(and soon on the operators ML).

If you were a consumer of those and will miss them, please explain why.
In particular, please let us know how consuming that version (which was
only made available every n months) is significantly better than picking
your preferred time and get all the current stable branch HEADs at that
time.

Thanks in advance for your feedback,

[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

--
Thierry Carrez (ttx)

This is generally my opinion as-well, I always hoped that every
commit would be considered a release rather than an arbitrary tagged
date. This empowers vendors and distributors to create their own
service pack style update on a cadence that suits their requirements
and users, rather than feeling tied to cross-vendor schedule or
feeling bad picking interim commits.

The primary push back on this when we started the stable branches was
a vendor wanting to have known release versions for their customers,
and I don't think we have had comment from that (or all) vendors. I
hope this is seen as a positive thing, as it really is IMO.

I have a question about still having library releases you mentioned,
as generally - everything in python is a library. I don't think we
have a definition of what in OpenStack is considered a mere library,
compared to a project that wouldn't have a release.

A library from an OpenStack POV, from my POV :), is anything that the
'server' projects, e.g. nova, cinder, keystone, glance, etc, depend on.
Primarily the oslo libraries, the clients, and everything they depend on.

It's probably easier to think of it as anything in the
global-requirements list:

https://github.com/openstack/requirements/blob/master/global-requirements.txt

Note that nova, keystone, glance, cinder, etc aren't in that list.

I also wondered if it might make sense for us to do a better job of
storing metadata of what the shasums of projects used to pass gate for
a given commit - as this might be both useful as a "known good state"
but also, slightly unrelated, might be helpful in debugging gate
blockages in the future.

Thanks

--
Kind Regards,
Dave Walker


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

--

Thanks,

Matt Riedemann


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 May 29, 2015 by Matt_Riedemann (48,320 points)   3 7 20
...