On Wed, Jun 9, 2021 at 11:06 AM Marios Andreou <marios@redhat.com> 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 or 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?


For me it's fine if TripleO provides a list of tags which are able to deploy and coinstall with a certain OpenStack release, let's say stable/Y, i don't see much problem on that, we'd need to figure out how to express that as code.

The actual problem I see is how to maintain that working overtime during the maintenance phase of release Y without stable/Y branches or CI jobs for old releases. Let's assume that at GA time for Y you provide a list of tags for tripleo projects coming from the master branch.  How will you manage a bug affecting to tripleo on release Y or introduced by any changing factor (OS updates, etc...)?, will master branch be kept tested and compatible with both master and stable/Y (as branchless project do, i.e. tempest)?. Note that frequent releases on master branches will not help to support Y release if a change in the branch depends on changes done in more recent releases.

From RDO, we don't require all packages to have stable branches (we include independent or branchless packages in the distro) but we want to provide a validated combination of packages working for a certain synchronized release and with the mechanism to fix it if it breaks during the maintenance period. I'm not sure how tripleo can do this without branches or maintaining backwards compatibility in master or other branches.
 

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




--
_sent from my mobile - sorry for spacing spelling etc_