On Wed, 2021-06-09 at 12:06 +0300, Marios Andreou wrote:
On Wednesday, June 9, 2021, Alfredo Moralejo Alonso <amoralej@redhat.com> wrote:
On Wed, Jun 9, 2021 at 2:48 AM Dan Sneddon <dsneddon@redhat.com> wrote:
Thanks for making the announcement. Can you clarify how the feature-freeze dates will be communicated to the greater community of contributors?
- Dan Sneddon
On Jun 8, 2021, at 8:21 AM, Wesley Hayutin <whayutin@redhat.com> wrote:
Greetings TripleO community!
At the most recent TripleO community meetings we have discussed formally changing the OpenStack release model for TripleO [1]. The previous released projects can be found here [2]. TripleO has previously released with release-type[‘trailing’, ‘cycle-with-intermediary’].
To quote the release model doc:
‘Trailing deliverables trail the release, so they cannot, by definition, be independent. They need to pick between cycle-with-rc <https://releases.openstack.org/reference/release_models.html#cycle-with-rc> or cycle-with-intermediary <https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary> models.’
We are proposing to update the release-model to ‘independent’. This would give the TripleO community more flexibility in when we choose to cut a release. In turn this would mean less backporting, less upstream and 3rd party resources used by potentially some future releases.
What does this change mean in terms of branches and compatibility for OpenStack stable releases?.
as i wrote to Dan just now the main thing is that we may delay or even skip a particular branch. For compatibility I guess it means we would have to rely on git tags so perhaps making consistently frequent (eg monthly? or more?) releases for all the tripleo repos. You could then call a particular range of tags as being compatible with stable/Y for example. Does it sound sane/doable from an rdo package build perspective?
too me this feels like we are leaking downstream product lifecycle into upstream. even if redhat is overwhelmingly the majority contibutor of reviews and commits to ooo im not sure that changing the upstream lifestyle to align more closely with our product life cycle is the correct thing to do. at least while tripleo is still in the Openstack namespaces and not the x namespaces. Skipping upstream release is really quite a radical departure form the project original goals. i think it would also be counter productive to our downstream efforts to move our testing close to upstream. if ooo was to lose the ablity to test master for example we would not be able to use ooo in our downstream ci to test feature that we plan to release osp n+1 that are develop during an upstream cycle that wont be productised. i do not work on ooo so at the end of the day this wont affect me much but to me skipping releases seam counter intuitive given the previous efforts to make ooo more usable for development and ci. Moving to independent to decouple the lifecycle seams more reasonable if the underlying goal is not to skip releases. you can release when ready rather then scrambling or wating for a deadline. personally i think moving in the other direction so that ooo can release sooner not later would make the project more appealing as the delay in support of a release is often considered a detractor for tripleo vs other openstack installers. i would hope that this change would not have any effect on the rdo packaging of non ooo packages. the rdo packages are used by other instalation methods (the puppet moduels for example) including i belive some of the larger chineese providers that have written there own installers. i think it would be damaging to centos if rdo was to skip upstream version of say nova. what might need to change is the packaging of ooo itself in rdo. tl;dr im not against the idea of ooo moving to independent model but i would hope that it will not affect RDO's packaging of non ooo projects and that ooo can still be used for ci of master and stable branches of for example nova. regards sean
regards, marios
To quote the release model doc:
‘Some projects opt to completely bypass the 6-month cycle and release independently. For example, that is the case of projects that support the development infrastructure. The “independent” model describes such projects.’
The discussion here is to merely inform the greater community with regards to the proposal and conversations regarding the release model. This thread is NOT meant to discuss previous releases or their supported status, merely changing the release model here [3]
[0] https://etherpad.opendev.org/p/tripleo-meeting-items
[1] https://releases.openstack.org/reference/release_models.html
[2] https://releases.openstack.org/teams/tripleo.html
[3] https://opendev.org/openstack/releases/src/branch/master/ deliverables/xena