Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
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 fu...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
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 zze...@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 fu...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
-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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
