<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 12, 2021 at 5:22 PM Alfredo Moralejo Alonso <<a href="mailto:amoralej@redhat.com">amoralej@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 12, 2021 at 3:32 PM Marios Andreou <<a href="mailto:marios@redhat.com" target="_blank">marios@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">hello TripleO,<br><br>per $subject I want to propose that tripleo-ipsec moves to the independent release model, as done recently for os-collect-config and friends at [1].<br><br>The tripleo-ipsec repo hasn't had much/any commits in the last year [2]. In fact, we hadn't even created a ussuri branch for this repo and no-one noticed (!).<br><br>Because of the lack of stable/ussuri some of the release jobs failed, as discussed at [3] and which ttx tried to fix (thank you!) with [4]. <br><br>Unfortunately this hasn't resolved the issue and jobs are still failing, as discussed just now in openstack-release [4]. If we agree to move tripleo-ipsec to independent then it will also resolve this build job issue.<br><br>If we move tripleo-ipsec to independent it means we can still release it if required, but we will no longer create stable/branches for the repo.<br><br>please voice any objections here or go and comment on the proposal at [6]<div><br></div></div></blockquote><div><br></div><div>The plan is to support any new tripleo-ipsec release on all supported openstack releases or just for master?<br></div></div></div></blockquote><div><br></div><div><br></div><div>honestly I don't expect many/any release requests here. After a while we can likely move this to retirement if no one is using and or maintaining it. But to answer your question and in the general case for any repo, 'I guess not' i.e. we would likely pin for each release as you propose below.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div>Just be aware that by default RDO follows stable branches for stable releases as it's not recommended to follow master branches in stable releases (although it may be justified in some cases). For projects with independent model you have two options to specify the version used on each stable release:</div><div><br></div><div>- Adding it to upper-constraints.txt as RDO follows the versions listed in that file.<br></div><div>- Pinning to specific commit or tag in rdoinfo for each release and manually proposing version bumps when needed.</div><div><br></div><div>Independent releases need a bit more attention in terms of deciding which version to use on each RDO release, I'm not saying it's a blocker but something to take into account after moving it to independent.</div><div><br></div></div></div></blockquote><div><br></div><div><br></div><div>thanks very much for your helpful comments. I think pinning is the way to go here. For this particular repo I don't expect much/any activity to be honest so the overhead of updating/bumping versions will be minimal/non existent. Can you point me to the file and I'll propose a review with the commits?</div><div><br></div><div>thanks, marios</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Regards,</div><div><br></div><div>Alfredo<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>thanks for reading!</div><div><br></div><div>regards, marios</div><div><br><br>[1] <a href="https://review.opendev.org/c/openstack/releases/+/772570" target="_blank">https://review.opendev.org/c/openstacreleasereleasek/releases/+/772570</a><br>[2] <a href="https://opendev.org/openstack/tripleo-ipsec/commits/branch/master" target="_blank">https://opendev.org/openstack/tripleo-ipsec/commits/branch/master</a><br>[3] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020112.html</a><br>[4] <a href="https://review.opendev.org/c/openstack/releases/+/772995" target="_blank">https://review.opendev.org/c/openstack/releases/+/772995</a><br>[5] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html" target="_blank">http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-02-12.log.html</a><br>[6] <a href="https://review.opendev.org/c/openstack/releases/+/775395" target="_blank">https://review.opendev.org/c/openstack/releases/+/775395</a><br></div></div>
</blockquote></div></div>
</blockquote></div></div>