settingsLogin | Registersettings

[openstack-dev] Targeting icehouse-eol?

0 votes

Following on the thread about no longer doing stable point releases [1]
at the summit we talked about doing icehouse-eol pretty soon [2].

I scrubbed the open stable/icehouse patches last week and we're down to
at least one screen of changes now [3].

My thinking was once we've processed that list, i.e. either approved
what we're going to approve or -2 what we aren't, then we should proceed
with doing the icehouse-eol tag and deleting the branch.

Is everyone generally in agreement with doing this soon? If so, then
I'm thinking target a week from today for the stable maint core team to
scrub the list of open reviews in the next week and we then get the
infra team to tag the branch and close it out.

The only open question I have is if we need to do an Icehouse point
release prior to the tag and dropping the branch, but I don't think
that's happened in the past with branch end of life - the eol tag
basically serves as the placeholder to the last 'release'.

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
[2] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch
[3] https://review.openstack.org/#/q/status:open+branch:stable/icehouse,n,z

--

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
asked Jun 3, 2015 in openstack-dev by Matt_Riedemann (48,320 points)   3 9 22

9 Responses

0 votes

On Wed, Jun 03, 2015 at 09:06:29AM -0500, Matt Riedemann wrote:
Following on the thread about no longer doing stable point releases [1] at
the summit we talked about doing icehouse-eol pretty soon [2].

I scrubbed the open stable/icehouse patches last week and we're down to at
least one screen of changes now [3].

My thinking was once we've processed that list, i.e. either approved what
we're going to approve or -2 what we aren't, then we should proceed with
doing the icehouse-eol tag and deleting the branch.

Is everyone generally in agreement with doing this soon? If so, then I'm
thinking target a week from today for the stable maint core team to scrub
the list of open reviews in the next week and we then get the infra team to
tag the branch and close it out.

Not really a surprise, but I support doing this soon. Next week seems fine
to me.

The only open question I have is if we need to do an Icehouse point release
prior to the tag and dropping the branch, but I don't think that's happened
in the past with branch end of life - the eol tag basically serves as the
placeholder to the last 'release'.

I don't think we need to do a point release, there will be the icehouse-eol
tag which will mark the same thing. But, even if we later decide to add a
point release to mark the same thing it is trivial to push another tag for
the same sha1.

-Matt Treinish


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 Jun 4, 2015 by Matthew_Treinish (11,200 points)   2 5 5
0 votes

Matthew Treinish wrote:
On Wed, Jun 03, 2015 at 09:06:29AM -0500, Matt Riedemann wrote:

Following on the thread about no longer doing stable point releases [1] at
the summit we talked about doing icehouse-eol pretty soon [2].

I scrubbed the open stable/icehouse patches last week and we're down to at
least one screen of changes now [3].

My thinking was once we've processed that list, i.e. either approved what
we're going to approve or -2 what we aren't, then we should proceed with
doing the icehouse-eol tag and deleting the branch.

Is everyone generally in agreement with doing this soon? If so, then I'm
thinking target a week from today for the stable maint core team to scrub
the list of open reviews in the next week and we then get the infra team to
tag the branch and close it out.

Not really a surprise, but I support doing this soon. Next week seems fine
to me.

Right, I also support doing this sometimes this month.

The only open question I have is if we need to do an Icehouse point release
prior to the tag and dropping the branch, but I don't think that's happened
in the past with branch end of life - the eol tag basically serves as the
placeholder to the last 'release'.

I don't think we need to do a point release, there will be the icehouse-eol
tag which will mark the same thing. But, even if we later decide to add a
point release to mark the same thing it is trivial to push another tag for
the same sha1.

I CC-ed the stable branch release managers for their opinion on it. We
definitely announced a 2014.1.5 last icehouse release, so I think we
should probably do one. Ideally we would have time to coordinate it in
the coming week so that both plans are compatible.

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

The only open question I have is if we need to do an Icehouse point release
prior to the tag and dropping the branch, but I don't think that's happened
in the past with branch end of life - the eol tag basically serves as the
placeholder to the last 'release'.

I don't think we need to do a point release, there will be the icehouse-eol
tag which will mark the same thing. But, even if we later decide to add a
point release to mark the same thing it is trivial to push another tag for
the same sha1.

I CC-ed the stable branch release managers for their opinion on it. We
definitely announced a 2014.1.5 last icehouse release, so I think we
should probably do one. Ideally we would have time to coordinate it in
the coming week so that both plans are compatible.

Based on previoius 15 months plan, 2014.1.5 was targeting July 2015,
so releasing it next week would be close enough:
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Ficehouse_releases

I'm not sure if release machinery would work after removing the branch
so let's release this last one (codename: Farewell ?) point release. I
can do this next week after we finish pending reviews.

Cheers,
Alan


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 Jun 4, 2015 by Alan_Pevec (5,300 points)   1 3 4
0 votes

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

On 06/04/2015 04:15 PM, Alan Pevec wrote:

The only open question I have is if we need to do an Icehouse
point release prior to the tag and dropping the branch, but I
don't think that's happened in the past with branch end of
life - the eol tag basically serves as the placeholder to the
last 'release'.

I don't think we need to do a point release, there will be the
icehouse-eol tag which will mark the same thing. But, even if
we later decide to add a point release to mark the same thing
it is trivial to push another tag for the same sha1.

I CC-ed the stable branch release managers for their opinion on
it. We definitely announced a 2014.1.5 last icehouse release, so
I think we should probably do one. Ideally we would have time to
coordinate it in the coming week so that both plans are
compatible.

Based on previoius 15 months plan, 2014.1.5 was targeting July
2015, so releasing it next week would be close enough:
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fi
cehouse_releases

I'm not sure if release machinery would work after removing the
branch so let's release this last one (codename: Farewell ?) point
release. I can do this next week after we finish pending reviews.

Why do we even drop stable branches? If anything, it introduces
unneeded problems to those who have their scripts/cookbooks set to
chase those branches. They would need to switch to eol tag. Why not
just leaving them sitting there, marked read only?

It becomes especially important now that we say that stable HEAD is
a stable release.

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

iQEcBAEBCAAGBQJVcF9MAAoJEC5aWaUY1u57MV8H/jOOJYo61Gkb4uC7sNrxi1Kf
WLRyA5f6ANecir7y05NbSvX4EaNgTZ5PeFbGwE3TJHIj/JSOu4lgRBYVyHh0Tm3x
wu9KBbB9Qa+jakvMgygwLYlaVNCyVDtfNGLlto9IxAvbfK00/Bn/6kktycezQBuQ
152esL2gh+L1f+K5EDdNhwPdLGVe4pMf8mr7575X6Zc2xnfHDtac8oJecIT7fKjT
0CCe/1CzlY8nV8OIYNa4C+p32VAeHk5BEVYmMOKYbtALDqsUBoZLivuONjMXRwwE
9OqrMk5wcCjMB4y+550RylzkSvnyEj++sM/yIK5TEq2AwzIhAA+HRskrhewquVs=
=C92c
-----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 Jun 4, 2015 by Ihar_Hrachyshka (35,300 points)   3 10 16
0 votes

On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote:
Why do we even drop stable branches? If anything, it introduces
unneeded problems to those who have their scripts/cookbooks set to
chase those branches. They would need to switch to eol tag. Why not
just leaving them sitting there, marked read only?

It becomes especially important now that we say that stable HEAD is
a stable release.

It's doable, but we'll need ACL changes applied to every project
participating in this release model to reject new change submissions
and prevent anyone from approving them on every branch which reaches
its EOL date. These ACLs will also grow longer and longer over time
as we need to add new sections for each EOL branch.

Also, it seems to me like a "feature" if downstream consumers have
to take notice and explicitly adjust their tooling to intentionally
continue deploying a release for which we no longer provide support
and security updates.
--
Jeremy Stanley


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 Jun 4, 2015 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

We can do the opposite to avoid more and more ACLs:

ALLOW push on some specific stable branches

[access "refs/heads/stable/kilo"]
push = allow group ***-stable-maint

[access "refs/heads/stable/juno"]
push = allow group ***-stable-maint

BLOCK push on others stable branches

[access "refs/heads/stable/juno"]
push = block group "Anonymous Users"

Cedric/ZZelle@IRC

On Thu, Jun 4, 2015 at 6:15 PM, Jeremy Stanley fungi@yuggoth.org wrote:

On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote:

Why do we even drop stable branches? If anything, it introduces
unneeded problems to those who have their scripts/cookbooks set to
chase those branches. They would need to switch to eol tag. Why not
just leaving them sitting there, marked read only?

It becomes especially important now that we say that stable HEAD is
a stable release.

It's doable, but we'll need ACL changes applied to every project
participating in this release model to reject new change submissions
and prevent anyone from approving them on every branch which reaches
its EOL date. These ACLs will also grow longer and longer over time
as we need to add new sections for each EOL branch.

Also, it seems to me like a "feature" if downstream consumers have
to take notice and explicitly adjust their tooling to intentionally
continue deploying a release for which we no longer provide support
and security updates.
--
Jeremy Stanley


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
responded Jun 4, 2015 by ZZelle (1,760 points)   2
0 votes

argh

BLOCK push on others stable branches

[access "refs/heads/stable/*"]
push = block group "Anonymous Users"

On Thu, Jun 4, 2015 at 6:34 PM, ZZelle zzelle@gmail.com wrote:

We can do the opposite to avoid more and more ACLs:

ALLOW push on some specific stable branches

[access "refs/heads/stable/kilo"]
push = allow group ***-stable-maint

[access "refs/heads/stable/juno"]
push = allow group ***-stable-maint

BLOCK push on others stable branches

[access "refs/heads/stable/juno"]
push = block group "Anonymous Users"

Cedric/ZZelle@IRC

On Thu, Jun 4, 2015 at 6:15 PM, Jeremy Stanley fungi@yuggoth.org wrote:

On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote:

Why do we even drop stable branches? If anything, it introduces
unneeded problems to those who have their scripts/cookbooks set to
chase those branches. They would need to switch to eol tag. Why not
just leaving them sitting there, marked read only?

It becomes especially important now that we say that stable HEAD is
a stable release.

It's doable, but we'll need ACL changes applied to every project
participating in this release model to reject new change submissions
and prevent anyone from approving them on every branch which reaches
its EOL date. These ACLs will also grow longer and longer over time
as we need to add new sections for each EOL branch.

Also, it seems to me like a "feature" if downstream consumers have
to take notice and explicitly adjust their tooling to intentionally
continue deploying a release for which we no longer provide support
and security updates.
--
Jeremy Stanley


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
responded Jun 4, 2015 by ZZelle (1,760 points)   2
0 votes

Why do we even drop stable branches? If anything, it introduces
unneeded problems to those who have their scripts/cookbooks set to
chase those branches. They would need to switch to eol tag.

Because they would otherwise expect updates which will never come.
They should take a notice and removing a branch is a clear enough
message that they're now on their own.

Cheers,
Alan


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 Jun 5, 2015 by Alan_Pevec (5,300 points)   1 3 4
0 votes

let's release this last one (codename: Farewell ?) point release. I
can do this next week after we finish pending reviews.

Remaining stable/icehouse reviews[1] have -2 or -1 except
https://review.openstack.org/176019 which I've asked
neutron-stable-maint to review.
Matt, anything else before we can tag 2014.1.5 and icehouse-eol ?

Cheers,
Alan

[1]
https://review.openstack.org/#/q/status:open+AND+branch:stable/icehouse+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove%29,n,z


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 Jun 16, 2015 by Alan_Pevec (5,300 points)   1 3 4
...