[all][release] One following-cycle release model to bind them all
Hi everyone, As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. We used to have a single model (with milestones and RCs) but over time we grew a number of alternative models to accommodate corner cases. The result is a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid. I'd like to suggest we simplify this and have a single model for things that follow the development cycle: the "follows-cycle" model. The only alternative, its nemesis, its Wario would be the "independent" release model. In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release. The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. I feel like this would not change that much for deliverables following the cycle-with-rc model. It would not change anything for cycle-with-intermediary, libraries or cycle-trailing deliverables. But it would simplify our processes quite a bit, and generally make our releases more consistent. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.htm... -- Thierry Carrez (ttx)
Hi, On 9 Jun 2020, 17:01 +0700, Thierry Carrez <thierry@openstack.org>, wrote:
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time.
I like this part because to me it feels like those RCs nowadays are often not necessary to do from development perspective but still "have to" because it’s just such a release process. On the other hand, RCs are useful when the project is really being actively developed (new features, refactoring etc) because it helps to get something pretending to be the final release but there’s still a chance to update it if testing helped find some issues. For what it’s worth, I think having less versions is better, especially if all artificial (procedural if you will) ones are gone. Less confusing for users and new contributors. Such confusions really happen once in a while in practice. Thanks Renat Akhmerov @Nokia
On 2020-06-09 12:00:14 +0200 (+0200), Thierry Carrez wrote:
In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release.
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. [...]
I suppose this will also have the effect that the official release tags will now appear in the history of the master branch. That will be nice. -- Jeremy Stanley
On Tue, 9 Jun 2020, 11:01 Thierry Carrez, <thierry@openstack.org> wrote:
Hi everyone,
As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models.
We used to have a single model (with milestones and RCs) but over time we grew a number of alternative models to accommodate corner cases. The result is a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid.
I'd like to suggest we simplify this and have a single model for things that follow the development cycle: the "follows-cycle" model. The only alternative, its nemesis, its Wario would be the "independent" release model.
In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release.
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time.
One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release. We do intend to be more prompt about our releases, but there is always something that comes up. We may end up having to choose between releasing with known issues vs. halting development for the next cycle. On the other hand, perhaps a little focus would help us to push it over the line faster.
I feel like this would not change that much for deliverables following the cycle-with-rc model. It would not change anything for cycle-with-intermediary, libraries or cycle-trailing deliverables. But it would simplify our processes quite a bit, and generally make our releases more consistent.
Thoughts?
[1]
http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.htm...
-- Thierry Carrez (ttx)
Do we have a list of projects that use alternative release model? And are these projects follow the same the alternative release model among them? From: Mark Goddard <mark@stackhpc.com> Sent: Tuesday, June 9, 2020 3:43 PM To: Thierry Carrez Cc: openstack-discuss Subject: Re: [all][release] One following-cycle release model to bind them all [EXTERNAL EMAIL] On Tue, 9 Jun 2020, 11:01 Thierry Carrez, <thierry@openstack.org<mailto:thierry@openstack.org>> wrote: Hi everyone, As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. We used to have a single model (with milestones and RCs) but over time we grew a number of alternative models to accommodate corner cases. The result is a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid. I'd like to suggest we simplify this and have a single model for things that follow the development cycle: the "follows-cycle" model. The only alternative, its nemesis, its Wario would be the "independent" release model. In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release. The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release. We do intend to be more prompt about our releases, but there is always something that comes up. We may end up having to choose between releasing with known issues vs. halting development for the next cycle. On the other hand, perhaps a little focus would help us to push it over the line faster. I feel like this would not change that much for deliverables following the cycle-with-rc model. It would not change anything for cycle-with-intermediary, libraries or cycle-trailing deliverables. But it would simplify our processes quite a bit, and generally make our releases more consistent. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.htm... -- Thierry Carrez (ttx)
Arkady.Kanevsky@dell.com wrote:
Do we have a list of projects that use alternative release model?
If you mean which service projects are currently using the "independent" model, today that would be only Rally. The other active "independent" deliverables are general-purpose libraries like reno or pbr, or xstatic packages (PyPI packaging of Javascript libraries).
And are these projects follow the same the alternative release model among them?
Could you rephrase that question? -- Thierry Carrez (ttx)
Mark Goddard wrote:
[...] One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release.
Making sure I understand... Currently you are using RC1 to create the stable branch, but it's not really a "release candidate", it's more a starting point for stabilization ? So you can have a broken master branch, tag it RC1 and create stable/ussuri from it, then work on making stable/ussuri releasable while keeping master broken ? If I understand correctly, then it's a fair point: the new model actually makes release candidates real release candidates, so it does not really support having a master branch that never gets close to releasable state. I would argue that this was not really the intent before with RC1 tags, but it certainly made it easier to hide. To support your case more clearly, maybe we could allow creating stable branches from arbitrary commit SHAs. It used to be the case before (when stable branches were created by humans) but when automation took over we enforced that branches need to be created from tags. I'll check with the release team where that requirement came from, and if we can safely relax it. -- Thierry Carrez (ttx)
On 2020-06-10 11:46, Thierry Carrez wrote:
Mark Goddard wrote:
[...] One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release.
Making sure I understand... Currently you are using RC1 to create the stable branch, but it's not really a "release candidate", it's more a starting point for stabilization ? So you can have a broken master branch, tag it RC1 and create stable/ussuri from it, then work on making stable/ussuri releasable while keeping master broken ?
If I understand correctly, then it's a fair point: the new model actually makes release candidates real release candidates, so it does not really support having a master branch that never gets close to releasable state. I would argue that this was not really the intent before with RC1 tags, but it certainly made it easier to hide.
To support your case more clearly, maybe we could allow creating stable branches from arbitrary commit SHAs. It used to be the case before (when stable branches were created by humans) but when automation took over we enforced that branches need to be created from tags.
I'll check with the release team where that requirement came from, and if we can safely relax it.
That would be great to have. Currently our RC1 is in no-touch state as it is broken by design (TM) and we always need to have RC2. :/ To summarize: nowadays we break our master branch to "release" half-broken RC1 to get a stable branch. Then we revert things on master to unbreak and work on stabilizing for release. -yoctozepto
On 6/10/20 11:46 AM, Thierry Carrez wrote:
Mark Goddard wrote:
[...] One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release.
Making sure I understand... Currently you are using RC1 to create the stable branch, but it's not really a "release candidate", it's more a starting point for stabilization ? So you can have a broken master branch, tag it RC1 and create stable/ussuri from it, then work on making stable/ussuri releasable while keeping master broken ?
If I understand correctly, then it's a fair point: the new model actually makes release candidates real release candidates, so it does not really support having a master branch that never gets close to releasable state. I would argue that this was not really the intent before with RC1 tags, but it certainly made it easier to hide.
To support your case more clearly, maybe we could allow creating stable branches from arbitrary commit SHAs.
This doesn't work, because downstream users of the upstream code have no way to know what upstream considers as the frozen-working-version. With RC1, we do know. Again, can we have a middle-ground where we have only a SINGLE rc release before the final one? For downstream distros (like Debian) I'd be easy to integrate patches to fix problems on top of this unique RC. Last, the RC doesn't have to be cut out of a stable branch. If that is the issue (ie: backporting to the stable branch before the release is a high cost), then the RC could be cut from master... Whatever is the best workflow upstream, I don't mind, as long as we have pre-release to eat for 1/ downstream distro 2/ config-management projects like Kola / OSA / puppet-openstack. Cheers, Thomas Goirand (zigo)
On Wed, 10 Jun 2020 at 10:47, Thierry Carrez <thierry@openstack.org> wrote:
Mark Goddard wrote:
[...] One substantial change here is that there will no longer be a period where the stable branch exists but the coordinated release does not. This could be an issue for cycle trailing projects such as kolla which sometimes get blocked on external (and internal) factors. Currently we are able to revert master from it's temporary stable mode to start development for the next cycle, while we continue stabilising the stable branch for release.
Making sure I understand... Currently you are using RC1 to create the stable branch, but it's not really a "release candidate", it's more a starting point for stabilization ? So you can have a broken master branch, tag it RC1 and create stable/ussuri from it, then work on making stable/ussuri releasable while keeping master broken ?
That's right. It's more incomplete than broken though. For example, RDO depends on Kolla's RC1 for it's GA, then we update the stable branch to install the RDO release RPM when it becomes available. There's also a slightly weird dance we have to do where we make master 'look like' the new release, by setting the branch name for our dependencies etc, then we revert those changes on master after the branch is cut. If the requirement to branch and RC1 at the same time was lifted it would avoid the need for this.
If I understand correctly, then it's a fair point: the new model actually makes release candidates real release candidates, so it does not really support having a master branch that never gets close to releasable state. I would argue that this was not really the intent before with RC1 tags, but it certainly made it easier to hide.
To support your case more clearly, maybe we could allow creating stable branches from arbitrary commit SHAs. It used to be the case before (when stable branches were created by humans) but when automation took over we enforced that branches need to be created from tags.
I think that would work well for us.
I'll check with the release team where that requirement came from, and if we can safely relax it.
-- Thierry Carrez (ttx)
On 6/9/20 12:00 PM, Thierry Carrez wrote:
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time.
tl;dr: If we do that, I wont be releasing packages the day of the release, and wont be able to get puppet-openstack for Debian ready on time either. Hi, So more or less, you're removing the mandatory release of frozen-before-release artifact.
From a downstream distribution package maintainer, I'd like to voice my concern that with this scheme, it's going to be very complicated to deliver the OpenStack release on-time when it gets released. This also means that it will be difficult to get things like puppet-openstack fixed on-time too, because they depend on the packages.
So, while I don't really mind the beta releases anymore (I don't package them these days), I do strongly believe that the RC releases are convenient. I don't think we need RC2, RC3, etc, but having a working RC1 2 or 3 weeks before the release is really a good thing which I would regret a lot if we decided not to do it anymore. Cheers, Thomas Goirand (zigo)
On 2020-06-10 15:11:35 +0200 (+0200), Thomas Goirand wrote:
On 6/9/20 12:00 PM, Thierry Carrez wrote: [...]
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. [...] So more or less, you're removing the mandatory release of frozen-before-release artifact.
From a downstream distribution package maintainer, I'd like to voice my concern that with this scheme, it's going to be very complicated to deliver the OpenStack release on-time when it gets released. This also means that it will be difficult to get things like puppet-openstack fixed on-time too, because they depend on the packages.
So, while I don't really mind the beta releases anymore (I don't package them these days), I do strongly believe that the RC releases are convenient. I don't think we need RC2, RC3, etc, but having a working RC1 2 or 3 weeks before the release is really a good thing which I would regret a lot if we decided not to do it anymore.
I don't understand what problem you're trying to convey. The suggestion is basically a cosmetic change, where instead of 14.0.0.0rc1 (and then if necessary 14.0.0.0rc2 and so on) we'd have 14.0.0 (and then if necessary 14.0.1 and so on). How does that change your packaging process? Is the concern that you can't know in advance what the release version number for a given service is going to be? -- Jeremy Stanley
On 6/10/20 3:23 PM, Jeremy Stanley wrote:
On 2020-06-10 15:11:35 +0200 (+0200), Thomas Goirand wrote:
On 6/9/20 12:00 PM, Thierry Carrez wrote: [...]
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. [...] So more or less, you're removing the mandatory release of frozen-before-release artifact.
From a downstream distribution package maintainer, I'd like to voice my concern that with this scheme, it's going to be very complicated to deliver the OpenStack release on-time when it gets released. This also means that it will be difficult to get things like puppet-openstack fixed on-time too, because they depend on the packages.
So, while I don't really mind the beta releases anymore (I don't package them these days), I do strongly believe that the RC releases are convenient. I don't think we need RC2, RC3, etc, but having a working RC1 2 or 3 weeks before the release is really a good thing which I would regret a lot if we decided not to do it anymore.
I don't understand what problem you're trying to convey. The suggestion is basically a cosmetic change, where instead of 14.0.0.0rc1 (and then if necessary 14.0.0.0rc2 and so on) we'd have 14.0.0 (and then if necessary 14.0.1 and so on). How does that change your packaging process? Is the concern that you can't know in advance what the release version number for a given service is going to be?
I don't buy into the "this is only cosmetic": that's not what's going to happen, unfortunately. Obviously, in your example, 14.0.0 will *NOT* be considered a pre-release of the next stable. 14.0.0 will be seen as the "final release" version, ie: the first stable version. This means that we wont have tags for the pre-release. If the issue is just cosmetic as you say, then let's keep rc1 as the name for the pre-release version. Cheers, Thomas Goirand (zigo)
On Wed, Jun 10, 2020 at 11:28 AM Thomas Goirand <thomas@goirand.fr> wrote:
On 6/10/20 3:23 PM, Jeremy Stanley wrote:
On 2020-06-10 15:11:35 +0200 (+0200), Thomas Goirand wrote:
On 6/9/20 12:00 PM, Thierry Carrez wrote: [...]
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. [...] So more or less, you're removing the mandatory release of frozen-before-release artifact.
From a downstream distribution package maintainer, I'd like to voice my concern that with this scheme, it's going to be very complicated to deliver the OpenStack release on-time when it gets released. This also means that it will be difficult to get things like puppet-openstack fixed on-time too, because they depend on the packages.
So, while I don't really mind the beta releases anymore (I don't package them these days), I do strongly believe that the RC releases are convenient. I don't think we need RC2, RC3, etc, but having a working RC1 2 or 3 weeks before the release is really a good thing which I would regret a lot if we decided not to do it anymore.
I don't understand what problem you're trying to convey. The suggestion is basically a cosmetic change, where instead of 14.0.0.0rc1 (and then if necessary 14.0.0.0rc2 and so on) we'd have 14.0.0 (and then if necessary 14.0.1 and so on). How does that change your packaging process? Is the concern that you can't know in advance what the release version number for a given service is going to be?
I don't buy into the "this is only cosmetic": that's not what's going to happen, unfortunately. Obviously, in your example, 14.0.0 will *NOT* be considered a pre-release of the next stable. 14.0.0 will be seen as the "final release" version, ie: the first stable version. This means that we wont have tags for the pre-release.
If the issue is just cosmetic as you say, then let's keep rc1 as the name for the pre-release version.
Cheers,
Thomas Goirand (zigo)
I'm not seeing any issues with this downstream in Ubuntu. It'll be the same as handling openstack dependency releases today. Semantic versioning will tell you if it's bug fixes only. Corey
On 2020-06-10 17:15:46 +0200 (+0200), Thomas Goirand wrote: [...]
I don't buy into the "this is only cosmetic": that's not what's going to happen, unfortunately. Obviously, in your example, 14.0.0 will *NOT* be considered a pre-release of the next stable. 14.0.0 will be seen as the "final release" version, ie: the first stable version.
That's no different from how it works now, other than the actual characters in the version string. Currently most projects cut a stable/whatever branch from an rc1 tag and then the same commit which got that rc1 tag gets re-tagged with the release version tag. In Thierry's proposal we'd just use an actual release-numbered tag rather than an rc1 tag. Projects which previously got an rc2 in their stable branch before the official coordinated release date would do a .1 point release there instead.
This means that we wont have tags for the pre-release.
We will, they'll just have release-like numbers on them (but the third component of the release number may not be the same if a patch version is tagged in that stable branch prior to the coordinated release). In Thierry's example, 14.0.0 is a candidate for the coordinated release just like 14.0.0.0rc1 would have been, but if issues are found with it then there could be a 14.0.0.1 before the coordinated release date, similar to 14.0.0.0rc2. The same factors which drive some projects to need a second (or third, or fourth) release candidate would still be present to cause them to want a second (or third, or fourth) patch version before the coordinated release date.
If the issue is just cosmetic as you say, then let's keep rc1 as the name for the pre-release version.
The workflow difference is primarily cosmetic (other than not necessarily needing to re-tag the last release candidate at coordinated release time). The issue it solves is not cosmetic: we currently have two primary release models, one for services and another for libraries. This would result in following the same model for services as we've been using to release libraries for years, just at a different point in the cycle than when libraries are released. -- Jeremy Stanley
On 6/10/20 6:56 PM, Jeremy Stanley wrote:
This means that we wont have tags for the pre-release.
We will, they'll just have release-like numbers on them
It doesn't make sense.
If the issue is just cosmetic as you say, then let's keep rc1 as the name for the pre-release version.
The workflow difference is primarily cosmetic (other than not necessarily needing to re-tag the last release candidate at coordinated release time).
Is the re-tag of services THAT time/resource consuming?
The issue it solves is not cosmetic: we currently have two primary release models, one for services and another for libraries. This would result in following the same model for services as we've been using to release libraries for years, just at a different point in the cycle than when libraries are released.
When I'll look into my Debian Q/A page [1] I wont be able to know if I missed packaging final release just by looking at version numbers (ie: track if there's still some RC version remaining and fix...). I'd be for the opposite move: tagging libraries as RC before the final release would make a lot of sense, and help everyone identify what these versions represent. On 6/10/20 6:33 PM, Mark Goddard wrote:
I think the issue is that currently there is a period of time in which every project has a release candidate which can be packaged and tested, prior to the release. In the new model there is no obligation to release anything prior to GA, and I expect most teams would not.
There's also that above that Mark wrote... On 6/10/20 7:05 PM, Jeremy Stanley wrote:
You and I clearly read very different proposals then. My understanding is that this does not get rid of the period of time you're describing, just changes the tags we use in it:
With this proposal, every project will treat the scheduled first RC as the release time itself, and move on to work on master. Even worse: since they are supposed to be just RC, you'll see that projects will care less to be on-time for it, and the final version from projects will be cut in a period varying from start of what we used to call the RC1, to the final release date. So this effectively, removes the pre-release period which we used to have dedicated for debugging and stabilising. On 6/10/20 6:56 PM, Jeremy Stanley wrote:
I think the proposal has probably confused some folks by saying, "stop having release candidates [...and instead have a] candidate for inclusion in the coordinated OpenStack release."
Jeremy, my opinion is that you are the person not understanding what this proposal implies, and what consequence it will have on how projects will release final versions.
It would basically still be a "release candidate" in spirit, just not in name, and not using the same tagging scheme as we have traditionally used for release candidates of service projects.
Please keep release candidate not just "in spirit", but effectively, with the correct name matching what they are supposed to be. Otherwise, you're effectively removing what the RCs were. If that is what you want to do (ie: stop having release candidates), because of various reasons, just explain why and move on. I would understand such a move: - if we declare OpenStack more mature, and needing less care for coordinated releases. - if there's not enough people working on stable branches between RC and final releases. - if OpenStack isn't producing lots of bug-fixes after the first RCs, and they are now useless. I wouldn't understand if RC versions would be gone, just because numbers don't look pretty. That's IMO a wrong answer to a wrong problem. Cheers, Thomas Goirand (zigo) [1] https://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debia...
On 2020-06-10 23:56:41 +0200 (+0200), Thomas Goirand wrote: [...]
Is the re-tag of services THAT time/resource consuming? [...]
It means divergent tooling and process for releasing our libraries vs releasing our services, and additional cognitive load for projects to need to decide which deliverables should follow what release model.
When I'll look into my Debian Q/A page [1] I wont be able to know if I missed packaging final release just by looking at version numbers (ie: track if there's still some RC version remaining and fix...).
You don't know that today for our libraries either, since they branch from non-rc version numbers and may produce additional point releases in their stable/$cycle branch up until near the coordinated release.
I'd be for the opposite move: tagging libraries as RC before the final release would make a lot of sense, and help everyone identify what these versions represent. [...]
Except that they typically branch long, long before the coordinated release and need to have their version numbers included in requirements lists for other projects' master branches. It might be doable to have them use release candidates on the new stable branch until close to coordinated release and then tag them all with version numbers and update every requirements list to compensate, but that seems like it would turn into a massive scramble vs the one patch version here and there that they normally accrue late in the cycle.
With this proposal, every project will treat the scheduled first RC as the release time itself, and move on to work on master.
They already do. Right now when rc1 is tagged and the stable/$cycle branch is created from it, subsequent fixes enter master and get backported to stable/$cycle and then an rc2 (or 3, or 4...) is tagged in stable/$cycle as needed. At coordinated release time whatever the corresponding commit was for the last rcN tag was gets re-tagged as the release version, and in most cases that's identical to the rc1 tag (no additional fixes during release candidate period). The new proposal would follow the same process, just not stick rcN prefixes on the tags and increment the last number in the tag instead, then not do any re-tagging of the last tag at coordinated release time because the versions of the last tags are already normal version numbers.
Even worse: since they are supposed to be just RC, you'll see that projects will care less to be on-time for it, and the final version from projects will be cut in a period varying from start of what we used to call the RC1, to the final release date.
I don't see why you would expect this any more than today. Projects backport patches from master to the new stable/$cycle branch during this period already, the incentive to do that doesn't change based on what the tags created in that branch look like.
So this effectively, removes the pre-release period which we used to have dedicated for debugging and stabilising. [...]
You keep asserting this, but the plan is precisely intended to maintain this period, and says nothing about getting rid of it.
If that is what you want to do (ie: stop having release candidates), because of various reasons, just explain why and move on. I would understand such a move: - if we declare OpenStack more mature, and needing less care for coordinated releases. - if there's not enough people working on stable branches between RC and final releases. - if OpenStack isn't producing lots of bug-fixes after the first RCs, and they are now useless. [...]
The original plan as written explains exactly why: "We [...have] a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid." We already ask far too much of our project teams, and simplifying the release models and processes they have to understand and follow should ease some of their overall burden, freeing up their time for more important remaining tasks. -- Jeremy Stanley
Hi, On Wed, Jun 10, 2020 at 11:59 PM Thomas Goirand <zigo@debian.org> wrote:
On 6/10/20 6:56 PM, Jeremy Stanley wrote:
This means that we wont have tags for the pre-release.
We will, they'll just have release-like numbers on them
It doesn't make sense.
If the issue is just cosmetic as you say, then let's keep rc1 as the name for the pre-release version.
The workflow difference is primarily cosmetic (other than not necessarily needing to re-tag the last release candidate at coordinated release time).
Is the re-tag of services THAT time/resource consuming?
The issue it solves is not cosmetic: we currently have two primary release models, one for services and another for libraries. This would result in following the same model for services as we've been using to release libraries for years, just at a different point in the cycle than when libraries are released.
When I'll look into my Debian Q/A page [1] I wont be able to know if I missed packaging final release just by looking at version numbers (ie: track if there's still some RC version remaining and fix...).
How do you solve it for thousands of other packages that don't do RC?
I'd be for the opposite move: tagging libraries as RC before the final release would make a lot of sense, and help everyone identify what these versions represent.
On 6/10/20 6:33 PM, Mark Goddard wrote:
I think the issue is that currently there is a period of time in which every project has a release candidate which can be packaged and tested, prior to the release. In the new model there is no obligation to release anything prior to GA, and I expect most teams would not.
There's also that above that Mark wrote...
On 6/10/20 7:05 PM, Jeremy Stanley wrote:
You and I clearly read very different proposals then. My understanding is that this does not get rid of the period of time you're describing, just changes the tags we use in it:
With this proposal, every project will treat the scheduled first RC as the release time itself, and move on to work on master. Even worse: since they are supposed to be just RC, you'll see that projects will care less to be on-time for it, and the final version from projects will be cut in a period varying from start of what we used to call the RC1, to the final release date.
In ironic we have been doing what Thierry proposed for years without seeing any negative effects. And yes, the first RC *is* a release, so the projects will pretty rightfully treat it like that.
So this effectively, removes the pre-release period which we used to have dedicated for debugging and stabilising.
Maybe it works this way for Nova and other core projects, but it has never worked for everyone else. People either consume master (like RDO) or final releases (like pretty much every final consumer). Maybe, judging by your messages, Debian was actually the (only) consumer that cared about RC releases, although I cannot comment on how much actual testing we got specifically from people installing RC releases from Debian. Dmitry
On 6/10/20 6:56 PM, Jeremy Stanley wrote:
I think the proposal has probably confused some folks by saying, "stop having release candidates [...and instead have a] candidate for inclusion in the coordinated OpenStack release."
Jeremy, my opinion is that you are the person not understanding what this proposal implies, and what consequence it will have on how projects will release final versions.
It would basically still be a "release candidate" in spirit, just not in name, and not using the same tagging scheme as we have traditionally used for release candidates of service projects.
Please keep release candidate not just "in spirit", but effectively, with the correct name matching what they are supposed to be. Otherwise, you're effectively removing what the RCs were.
If that is what you want to do (ie: stop having release candidates), because of various reasons, just explain why and move on. I would understand such a move: - if we declare OpenStack more mature, and needing less care for coordinated releases. - if there's not enough people working on stable branches between RC and final releases. - if OpenStack isn't producing lots of bug-fixes after the first RCs, and they are now useless.
I wouldn't understand if RC versions would be gone, just because numbers don't look pretty. That's IMO a wrong answer to a wrong problem.
Cheers,
Thomas Goirand (zigo)
[1]
https://qa.debian.org/developer.php?login=openstack-devel@lists.alioth.debia...
On Wed, 10 Jun 2020 at 14:24, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-06-10 15:11:35 +0200 (+0200), Thomas Goirand wrote:
On 6/9/20 12:00 PM, Thierry Carrez wrote: [...]
instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. [...] So more or less, you're removing the mandatory release of frozen-before-release artifact.
From a downstream distribution package maintainer, I'd like to voice my concern that with this scheme, it's going to be very complicated to deliver the OpenStack release on-time when it gets released. This also means that it will be difficult to get things like puppet-openstack fixed on-time too, because they depend on the packages.
So, while I don't really mind the beta releases anymore (I don't package them these days), I do strongly believe that the RC releases are convenient. I don't think we need RC2, RC3, etc, but having a working RC1 2 or 3 weeks before the release is really a good thing which I would regret a lot if we decided not to do it anymore.
I don't understand what problem you're trying to convey. The suggestion is basically a cosmetic change, where instead of 14.0.0.0rc1 (and then if necessary 14.0.0.0rc2 and so on) we'd have 14.0.0 (and then if necessary 14.0.1 and so on). How does that change your packaging process? Is the concern that you can't know in advance what the release version number for a given service is going to be?
I think the issue is that currently there is a period of time in which every project has a release candidate which can be packaged and tested, prior to the release. In the new model there is no obligation to release anything prior to GA, and I expect most teams would not.
-- Jeremy Stanley
On 2020-06-10 17:33:55 +0100 (+0100), Mark Goddard wrote: [...]
I think the issue is that currently there is a period of time in which every project has a release candidate which can be packaged and tested, prior to the release. In the new model there is no obligation to release anything prior to GA, and I expect most teams would not.
You and I clearly read very different proposals then. My understanding is that this does not get rid of the period of time you're describing, just changes the tags we use in it: [Excerpt from Thierry's original post yesterday...]
The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release.
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release.
For service projects, that "deadline" he talks about would be the start of the traditional RC period, we just wouldn't use special rc1 tags for branching at that point, we'd use actual version numbers to branch from. I think the proposal has probably confused some folks by saying, "stop having release candidates [...and instead have a] candidate for inclusion in the coordinated OpenStack release." It would basically still be a "release candidate" in spirit, just not in name, and not using the same tagging scheme as we have traditionally used for release candidates of service projects. -- Jeremy Stanley
On Wed, 10 Jun 2020 at 18:06, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-06-10 17:33:55 +0100 (+0100), Mark Goddard wrote: [...]
I think the issue is that currently there is a period of time in which every project has a release candidate which can be packaged and tested, prior to the release. In the new model there is no obligation to release anything prior to GA, and I expect most teams would not.
You and I clearly read very different proposals then.
Friendlier wording: we interpreted it differently.
My understanding is that this does not get rid of the period of time you're describing, just changes the tags we use in it:
[Excerpt from Thierry's original post yesterday...]
The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release.
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release.
For service projects, that "deadline" he talks about would be the start of the traditional RC period, we just wouldn't use special rc1 tags for branching at that point, we'd use actual version numbers to branch from. I think the proposal has probably confused some folks by saying, "stop having release candidates [...and instead have a] candidate for inclusion in the coordinated OpenStack release." It would basically still be a "release candidate" in spirit, just not in name, and not using the same tagging scheme as we have traditionally used for release candidates of service projects.
I think this is reading between the lines somewhat. I agree that it makes sense however, and preserves the period before release during which every deliverable to be included in GA should have a release available.
-- Jeremy Stanley
Mark Goddard wrote:
[Excerpt from Thierry's original post yesterday...]
The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release.
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release.
For service projects, that "deadline" he talks about would be the start of the traditional RC period, we just wouldn't use special rc1 tags for branching at that point, we'd use actual version numbers to branch from. I think the proposal has probably confused some folks by saying, "stop having release candidates [...and instead have a] candidate for inclusion in the coordinated OpenStack release." It would basically still be a "release candidate" in spirit, just not in name, and not using the same tagging scheme as we have traditionally used for release candidates of service projects.
I think this is reading between the lines somewhat. I agree that it makes sense however, and preserves the period before release during which every deliverable to be included in GA should have a release available.
To clarify, the intent is definitely to keep a stabilization period between the moment the branch is created and the "final" coordinated release date. We currently do it by asking projects to release a "RC1" which coincides with the branching, and then have them iterate on tagging further RCx versions (usually just one). The last available version at coordinated release date is re-tagged as a "normal" release number. With the unified model, projects would create the stabilization branch when they feel like it, then iterate on tagging versions (usually just one). The last available version at coordinated release date is considered included in the "OpenStack" release, without the need for a re-tag. Also to clarify, we are /already/ using that model for all cycle-with-intermediary deliverables like Swift or Ironic or Karbor or Vitrage or Monasca or CloudKitty or Horizon... It's not as if it was a new thing that would break packagers workflows. They already support it. If anything, it simplifies the workflow by making everything available ahead of time, rather than artificially trigger a bunch of new versions on release day as we re-tag the final RCs into correct release numbers. -- Thierry Carrez (ttx)
On Thursday, 11 June 2020 12:23:27 CEST Thierry Carrez wrote:
Mark Goddard wrote:
[Excerpt from Thierry's original post yesterday...]
The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release.
The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release.
For service projects, that "deadline" he talks about would be the start of the traditional RC period, we just wouldn't use special rc1 tags for branching at that point, we'd use actual version numbers to branch from. I think the proposal has probably confused some folks by saying, "stop having release candidates [...and instead have a] candidate for inclusion in the coordinated OpenStack release." It would basically still be a "release candidate" in spirit, just not in name, and not using the same tagging scheme as we have traditionally used for release candidates of service projects.
I think this is reading between the lines somewhat. I agree that it makes sense however, and preserves the period before release during which every deliverable to be included in GA should have a release available.
To clarify, the intent is definitely to keep a stabilization period between the moment the branch is created and the "final" coordinated release date.
We currently do it by asking projects to release a "RC1" which coincides with the branching, and then have them iterate on tagging further RCx versions (usually just one). The last available version at coordinated release date is re-tagged as a "normal" release number.
With the unified model, projects would create the stabilization branch when they feel like it, then iterate on tagging versions (usually just one). The last available version at coordinated release date is considered included in the "OpenStack" release, without the need for a re-tag.
Also to clarify, we are /already/ using that model for all cycle-with-intermediary deliverables like Swift or Ironic or Karbor or Vitrage or Monasca or CloudKitty or Horizon... It's not as if it was a new thing that would break packagers workflows. They already support it.
Can we at least enforce a rule that when tagging the "OpenStack" release, the y number should be increased? Bonus points for having the stabilization (RC) release use y=0, and the stable one starts from y=1. I know it may not sound to important for a computer, but it's useful for a human eye to know that the first release has a final 0 somewhere? (I really dislike the apache and mysql model in this regard) Ciao -- Luigi
On 2020-06-11 14:05:18 +0200 (+0200), Luigi Toscano wrote: [...]
Can we at least enforce a rule that when tagging the "OpenStack" release, the y number should be increased? Bonus points for having the stabilization (RC) release use y=0, and the stable one starts from y=1.
I know it may not sound to important for a computer, but it's useful for a human eye to know that the first release has a final 0 somewhere? (I really dislike the apache and mysql model in this regard)
As pointed out, this already isn't the case for the many projects currently following this model, especially those which branch earlier in the cycle. It's also a bit of a puzzle... basically every new release you tag on the stable branch could be your final release, so how do you predict in advance that you won't need additional patches? I guess you could make every new tag in stable prior to the release a semantic versioning "feature" addition (even though it's really just patch level fixes), so you branch at 14.0.0, and then decide you need some fixes and tag 14.1.0, and then realize you need more fixes so tag 14.2.0, but then after the coordinated release you only increase the patch level of the version to 14.2.1, 14.2.2 and so on. Is that basically what you're suggesting? -- Jeremy Stanley
On Thursday, 11 June 2020 14:16:34 CEST Jeremy Stanley wrote:
On 2020-06-11 14:05:18 +0200 (+0200), Luigi Toscano wrote: [...]
Can we at least enforce a rule that when tagging the "OpenStack" release, the y number should be increased? Bonus points for having the stabilization (RC) release use y=0, and the stable one starts from y=1.
I know it may not sound to important for a computer, but it's useful for a human eye to know that the first release has a final 0 somewhere? (I really dislike the apache and mysql model in this regard)
As pointed out, this already isn't the case for the many projects currently following this model, especially those which branch earlier in the cycle. It's also a bit of a puzzle... basically every new release you tag on the stable branch could be your final release, so how do you predict in advance that you won't need additional patches?
We are doing time-based release, so we know which is the last version. We know it now (and we call it something.other.0), it would be in the case we moved forward with this exact proposal (but it would be called something.other.somethingelse). Just make sure you bump y too and still use .0 for that specific release. Of course there will be others bugfixes, exactly like we have now. I'm just talking about still retaining a way to more easily identify the first offiical tagged version for a specific coordinated OpenStack release.
I guess you could make every new tag in stable prior to the release a semantic versioning "feature" addition (even though it's really just patch level fixes), so you branch at 14.0.0, and then decide you need some fixes and tag 14.1.0, and then realize you need more fixes so tag 14.2.0, but then after the coordinated release you only increase the patch level of the version to 14.2.1, 14.2.2 and so on. Is that basically what you're suggesting?
You may need to also increase .y after the coordinated release (or so it has happened), so not sure it could be done. But as I said I'm focusing on the 1st release. That said, do projects which tag early needs to increase .y in the time between their first release for a certain cycle and the official first coordinate release? Is the time so long that it may happen? If it's not the case, then I believe that: 14.0.whatever -> during rc time 14.1.0 -> official release 14.y.z, y>=1 rest of lifecycle It means an extra tag if there are no changes between the tagging of 14.0.0 and the tagging of the coodinated release, but I guess that case can be automated. -- Luigi
On 2020-06-11 14:44:19 +0200 (+0200), Luigi Toscano wrote: [...]
We are doing time-based release, so we know which is the last version. We know it now (and we call it something.other.0), it would be in the case we moved forward with this exact proposal (but it would be called something.other.somethingelse).
How about a concrete example from the last cycle... Horizon. At the time of the Train coordinated release, the latest version of Horizon was 16.0.0 (since then Horizon has tagged 16.1.0 and 16.2.0 in their stable/train branch). In their master branch during the Ussuri cycle, Horizon made some backward-incompatible changes and tagged 17.0.0, then made feature changes and followed that with 17.1.0, then made some more backward-incompatible changes and tagged 18.0.0, then more feature changes for 18.1.0, 18.2.0, 18.3.0... at that point the end of the cycle was nearing so they branched stable/ussuri from the 18.3.0 tag, but still had some fixes in master to backport after that for the coordinated Ussuri release which resulted in 18.3.1 and 18.3.2 tags. At the time of the Ussuri coordinated release the latest version of Horizon in stable/ussuri was 18.3.2 so that's what was announced as part of the coordinated release.
Just make sure you bump y too and still use .0 for that specific release.
So to be clear, applying your suggestion to the Horizon example above, after they branched stable/ussuri they should only have done feature-level semantic versioning increases, tagging 18.4.0 and 18.5.0 instead of 18.3.1 and 18.3.2?
Of course there will be others bugfixes, exactly like we have now. I'm just talking about still retaining a way to more easily identify the first offiical tagged version for a specific coordinated OpenStack release. [...]
And in your opinion, 18.5.0 looks more official than 18.3.2 as a part of the coordinated release? Keep in mind that over the course of the Ussuri cycle, Horizon tagged no fewer than 6 new versions ending in .0 so are you similarly concerned that those might look "too official" when they were just marking points in master branch development?
You may need to also increase .y after the coordinated release (or so it has happened), so not sure it could be done. But as I said I'm focusing on the 1st release.
Yes, projects who are concerned with doing that (remember that those following stable branch policy should *not* merge changes which would require a feature level semantic version increase in their stable branches) can artificially increase the first version component in master to make sure it will always be greater than any feature bumps in latest stable.
That said, do projects which tag early needs to increase .y in the time between their first release for a certain cycle and the official first coordinate release? Is the time so long that it may happen? If it's not the case, then I believe that:
14.0.whatever -> during rc time 14.1.0 -> official release 14.y.z, y>=1 rest of lifecycle
It means an extra tag if there are no changes between the tagging of 14.0.0 and the tagging of the coodinated release, but I guess that case can be automated.
It already is automated with the re-tagging of the latest rcN version to some release version in cycle-with-rc projects today, and this re-tagging dance is a big part of what we're hoping to do away with to simplify the release process. If it really is important that the coordinated release versions have a .0 on the end of them, then I'd rather just have a policy that all subsequent versions tagged in stable branches before release day must be feature level semantic version increases rather than patch level. At least then nothing needs to be re-tagged. Granted, I find this slightly obsessive, and don't understand what's wrong with the many, many versions we include in our coordinated releases already which don't end in a .0 patch level. It also makes it harder to identify actual feature changes in libraries which need requirements freeze exceptions, and so will likely mean a lot more work on the requirements team to figure out if a new lib version is actually safe at that time (bug fixes masquerading as a feature increase). Your alternative, re-tagging them, means additional churn in requirements as well, at a rather disruptive time in the release cycle. -- Jeremy Stanley
To clarify, the intent is definitely to keep a stabilization period between the moment the branch is created and the "final" coordinated release date.
We currently do it by asking projects to release a "RC1" which coincides with the branching, and then have them iterate on tagging further RCx versions (usually just one). The last available version at coordinated release date is re-tagged as a "normal" release number.
With the unified model, projects would create the stabilization branch when they feel like it, then iterate on tagging versions (usually just one). The last available version at coordinated release date is considered included in the "OpenStack" release, without the need for a re-tag.
Also to clarify, we are /already/ using that model for all cycle-with-intermediary deliverables like Swift or Ironic or Karbor or Vitrage or Monasca or CloudKitty or Horizon... It's not as if it was a new thing that would break packagers workflows. They already support it. Can we at least enforce a rule that when tagging the "OpenStack" release, the y number should be increased? Bonus points for having the stabilization (RC) release use y=0, and the stable one starts from y=1.
I know it may not sound to important for a computer, but it's useful for a human eye to know that the first release has a final 0 somewhere? (I really dislike the apache and mysql model in this regard)
Ciao
One of the benefits of Thierry's proposal is it would eliminate the need to retag the last release in order to get the final coordinated release version. This would reintroduce the need to do that. So instead of retagging something like 12.0.0.0rc2 to be 12.0.0, we would be retagging 12.0.0 to be 12.0.1. If we think that is important, I would rather keep the RC designation on those stabilization releases to make sure it's clear what is officially ready, and what is in preparation to be deemed officially ready. One other challenge I see with getting rid of RCs would be what would be allowed to be merged. Only occasionally, but it does happen, we need to merge something during the RC period that would be considered a breaking change. We find a bug that requires reverting a patch that added a config option. Or we need to fix a bug by changing the default value for a config option. Or some other weird major change. If we are strictly enforcing SemVer rules, that could mean that a project could release a final end of cycle 12.0.0 release, then within a week or two need to release a 13.0.0 release because of that one breaking change. They are just numbers to convey what is included, so it's not like that is not possible to do. But I think that could cause confusion for downstream and potentially could cause issues with someone picking up that 12.0.0 major release thinking it is legitimate, not realizing that 13.0.0 is actually a fix for some issue in it. Again, minor concerns, but something we should be aware of thinking through how things would work. Sean
Thierry Carrez wrote:
As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. [...]
After having discussed this here and in several IRC discussions, there appears to still be enough cases warranting keeping two cycle-tied models (one with RCs and a round version number, the other strictly following semver). The simplification gains may not be worth disrupting long-established habits and tweaking all our validation toolchain. Instead, I'll work on improving documentation to guide new deliverables in this choice, and reduce corner cases and exceptions. Thanks for entertaining the idea and reaching out. Periodically reconsidering why we do things the way we do them is healthy, and avoids cargo-culting processes forever. -- Thierry Carrez (ttx)
After having discussed this here and in several IRC discussions, there appears to still be enough cases warranting keeping two cycle-tied models (one with RCs and a round version number, the other strictly following semver). The simplification gains may not be worth disrupting long-established habits and tweaking all our validation toolchain.
Instead, I'll work on improving documentation to guide new deliverables in this choice, and reduce corner cases and exceptions.
Thanks for entertaining the idea and reaching out. Periodically reconsidering why we do things the way we do them is healthy, and avoids cargo-culting processes forever.
Thanks for bringing up the idea Thierry. I agree, it's worth looking at what we're doing and why occasionally to make sure we're not doing things just because "that's what we do." I think some good feedback came out of all of this at least, so maybe we can still simplify some things, even if we can't fully collapse our release models. Sean
On Fri, 12 Jun 2020 at 13:02, Sean McGinnis <sean.mcginnis@gmx.com> wrote:
After having discussed this here and in several IRC discussions, there appears to still be enough cases warranting keeping two cycle-tied models (one with RCs and a round version number, the other strictly following semver). The simplification gains may not be worth disrupting long-established habits and tweaking all our validation toolchain.
Instead, I'll work on improving documentation to guide new deliverables in this choice, and reduce corner cases and exceptions.
Thanks for entertaining the idea and reaching out. Periodically reconsidering why we do things the way we do them is healthy, and avoids cargo-culting processes forever.
Thanks for bringing up the idea Thierry. I agree, it's worth looking at what we're doing and why occasionally to make sure we're not doing things just because "that's what we do."
I think some good feedback came out of all of this at least, so maybe we can still simplify some things, even if we can't fully collapse our release models.
I would be interested in a relaxation of the requirement for RC1 and stable branch cut to coincide, if possible. This would simplify the kolla release process.
Sean
Mark Goddard wrote:
On Fri, 12 Jun 2020 at 13:02, Sean McGinnis <sean.mcginnis@gmx.com> wrote:
I think some good feedback came out of all of this at least, so maybe we can still simplify some things, even if we can't fully collapse our release models.
I would be interested in a relaxation of the requirement for RC1 and stable branch cut to coincide, if possible. This would simplify the kolla release process.
We looked into that and it appears release note generation (through reno) might rely on tags at the start of stable branches in order to properly compute which changes apply where. So for the moment we'll keep the requirement, until that limitation is lifted. -- Thierry Carrez (ttx)
On 6/12/20 11:16 AM, Thierry Carrez wrote:
Thierry Carrez wrote:
As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. [...]
After having discussed this here and in several IRC discussions, there appears to still be enough cases warranting keeping two cycle-tied models (one with RCs and a round version number, the other strictly following semver). The simplification gains may not be worth disrupting long-established habits and tweaking all our validation toolchain.
Instead, I'll work on improving documentation to guide new deliverables in this choice, and reduce corner cases and exceptions.
Thanks for entertaining the idea and reaching out. Periodically reconsidering why we do things the way we do them is healthy, and avoids cargo-culting processes forever.
Thanks for the idea, and considering opinions of others before moving forward. Much appreciated. Cheers, Thomas Goirand (zigo)
participants (12)
-
Arkady.Kanevsky＠dell.com
-
Corey Bryant
-
Dmitry Tantsur
-
Jeremy Stanley
-
Luigi Toscano
-
Mark Goddard
-
Radosław Piliszek
-
Renat Akhmerov
-
Sean McGinnis
-
Thierry Carrez
-
Thomas Goirand
-
Thomas Goirand