<div dir="ltr"><div dir="ltr">First, thanks for your answer.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 4 nov. 2020 à 15:50, Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> a écrit :<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>
<br>
On 11/4/20 7:31 AM, Herve Beraud wrote:<br>
> Greetings,<br>
> <br>
> Is it time for us to move some parts of Oslo to the independent release <br>
> model [1]?<br>
> <br>
> I think we could consider Oslo world is mostly stable enough to answer <br>
> yes to the previous question.<br>
> <br>
> However, the goal of this email is to trigger the debat and see which <br>
> deliverables could be transitioned to the independent model.<br>
> <br>
> Do we need to expect that major changes will happen within Oslo and who <br>
> could warrant to continue to follow cycle-with-intermediary model [2]?<br>
<br>
I would hesitate to try to predict the future on what will see major <br>
changes and what won't. I would prefer to look at this more from the <br>
perspective of what Oslo libraries are tied to the OpenStack version. <br>
For example, I don't think oslo.messaging should be moved to <br>
independent. It's important that RPC has a sane version to version <br>
upgrade path, and the easiest way to ensure that is to keep it on the <br>
regular cycle release schedule. The same goes for other libraries too: <br>
oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also <br>
things like oslo.config and oslo.context (I suspect contexts need to be <br>
release-specific, but maybe someone from a consuming project can weigh <br>
in). Even oslo.serialization could have upgrade impacts if it is being <br>
used to serialize internal data in a service.<br></blockquote><div><br></div><div>Agreed, the goal here isn't to try to move everything to the independent model but more to identify which projects could be eligible for this switch.</div><div>I strongly agree that the previous list of projects <span class="gmail-tlid-translation gmail-translation" lang="en"><span title="" class="gmail-">that you quote should stay binded to openstack cycles and should continue to rely on stable branches.<br></span></span></div><div><span class="gmail-tlid-translation gmail-translation" lang="en"><span title="" class="gmail-">These kinds of projects and also openstack's services are strongly tied to backends, their version,  and available APIs and so to openstack's series, so they must remain linked to them.</span></span></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>
That said, many of the others can probably be moved. oslo.i18n and <br>
oslo.upgradecheck are both pretty stable at this point and not really <br>
tied to a specific release. As long as we're responsible with any future <br>
changes to them it should be pretty safe to make them independent.<br></blockquote><div><br></div><div>Agreed.</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>
This does raise a question though: Are the benefits of going independent <br>
with the release model sufficient to justify splitting the release <br>
models of the Oslo projects? I assume the motivation is to avoid having <br>
to do as many backports of bug fixes, but if we're mostly doing this <br>
with low-volume, stable projects does it gain us that much?<br></blockquote><div><br></div><div>Yes, you're right, it could help us to reduce our needed maintenance and so our Oslo's activity in general.</div><div>Indeed, about 35 projects are hosted by Oslo and concerning the active maintainers the trend isn't on the rise.<span class="gmail-tlid-translation gmail-translation" lang="en"><span title="" class="gmail-"></span></span></div><div>So reducing the number of stable branches to maintain could benefit us, and it could be done by moving projects to an independent model.<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">
<br>
I guess I don't have a strong opinion one way or another on this yet, <br>
and would defer to our release liaisons if they want to go one way or <br>
other other. Hopefully this provides some things to think about though.<br></blockquote><div><br></div><div>Yes you provided interesting observations, thanks.</div><div>It could be interesting to get feedback from other cores.<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>
-Ben<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer at Red Hat</div><div>irc: hberaud</div><div><a href="https://github.com/4383/" target="_blank">https://github.com/4383/</a></div><div><a href="https://twitter.com/4383hberaud" target="_blank">https://twitter.com/4383hberaud</a><br></div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>