<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 28, 2021 at 8:22 PM Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</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">On 2/28/21 12:10 PM, Takashi Kajinami wrote:<br>
> <br>
> On Sun, Feb 28, 2021 at 3:32 AM Thomas Goirand <<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a><br>
> <mailto:<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> On 2/27/21 3:52 PM, Takashi Kajinami wrote:<br>
> > I have posted a comment on the said patch but I prefer using pyvers in<br>
> > that specific patch because;<br>
> > - The change seems to be a backport candidate and using pyvers<br>
> helps us<br>
> > backport the change<br>
> > to older branches like Train which still supports python 2 IIRC.<br>
> <br>
> Even Rocky is already using python3 in Debian/Ubuntu. The last distro<br>
> using the Python 2 version would be Stretch (which is long EOLed) and<br>
> Bionic (at this time, people should be moving to Focal, no ?, which IMO<br>
> are not targets for backports.<br>
> <br>
> Therefore, for this specific patch, even if you want to do a backport,<br>
> it doesn't make sense.<br>
> <br>
> Are you planning to do such a backport for the RPM world?<br>
> <br>
> We still have queens open for puppet-openstack modules.<br>
> IIRC rdo rocky is based on CentOS7 and Python2.<br>
> Also, I don't really like to see inconsistent implementation caused by<br>
> backport<br>
> knowing that we don't support python3 in these branches.<br>
> Anyway we can consider that when we actually backport the change.<br>
<br>
I'm a bit surprised that you still care about such an old release as<br>
Queens. Is this the release shipped with CentOS 7?<br></blockquote><div>RDO Queens anr RDO Rocky are based on CentOS 7.</div><div>RDO Train supports both CentOS7 and CentOS8 IIRC.</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">
In any ways, thanks for letting me know, I have to admit I don't know<br>
much about the RPM side of things.<br>
<br>
In such case, I'm ok to keep the ${pyvers} variable for the CentOS case<br>
for a bit longer then, but can we agree when we stop using it? Also IMO,<br>
forcing it for Debian/Ubuntu doesn't make sense anymore.<br></blockquote><div>IMO we can think about backport separately(we can make any required changes</div><div>in backport only) so we can get rid of pyvers in master for both CentOS and Ubuntu/Debian.</div><div><br></div><div>However I prefer to deal with that removal separately and consistently, so that we won't</div><div>create inconsistent implementation where some relies on pyvers and the others doesn't</div><div>rely on pyvers.<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">
<br>
Thanks everyone for participating in this thread,<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div><div dir="ltr"><div><div dir="ltr"><div><div style="outline:currentcolor none medium"><div dir="ltr"><br></div></div></div></div></div></div></div>