<div dir="ltr"><div>Thanks Julia for your response :)</div><div><br></div><div>I propose the following migration.</div><div><br></div><div>Transitioning to independent [1] model:</div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.i18</span></div><div><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">- </span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.log</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.reports</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.upgradecheck</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslotest</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">osprofiler</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">stevedore</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">taskflow</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">tooz</span></div><div><br></div><div>Remaining under the cycle-with-intermediary [2] model:</div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.concurrency</span></div><div><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">- </span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.config</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.context</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.db</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.limit</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.messaging</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.middleware</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.policy</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.privsep</span></div><div><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">- </span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.rootwrap</span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.serialization</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.service</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.utils</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.versionedobjects</span></div><div>- <span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z">oslo.vmware</span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span></div><div><br></div><div>I'll wait a bit before proposing the migration to allow everybody to react about the proposed lists.</div><div><br></div><div>Let me know if it makes sense for you and don't hesitate to debate on the proposed migration.<br></div><div><br></div><div>[1] <a href="https://releases.openstack.org/reference/release_models.html#independent">https://releases.openstack.org/reference/release_models.html#independent</a></div><div>[2] <a href="https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary">https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary</a></div><div><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"></span><span class="gmail-author-a-1xz70zwbz80zz75z3z81zooz69z4rcz85z"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 9 nov. 2020 à 17:15, Julia Kreger <<a href="mailto:juliaashleykreger@gmail.com">juliaashleykreger@gmail.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">Top posting because I'm a horrible person.<br>
<br>
Anyway, I think moving oslo to independent makes lots of sense, at<br>
least to me. The key I think is to have the ability to backport and<br>
release a patch/revisin/fix release if there is a major issue, but the<br>
obligation to backport or even set a foundation to do so is a whole<br>
other matter.<br>
<br>
My overall feeling, for something as stable as the oslo libraries,<br>
that cycle-with-intermediacy path may just end up being a frustrating<br>
headache, that is if the team feels confident and actively manages<br>
their own releases of the various libraries. Also, Under the existing<br>
model and policy of the release team, they would basically end up back<br>
where they started if the libraries failed to release multiple times,<br>
which may not make sense for stable libraries.<br>
<br>
Anyway, just my $0.02.<br>
<br>
-Julia<br>
<br>
On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud <<a href="mailto:hberaud@redhat.com" target="_blank">hberaud@redhat.com</a>> wrote:<br>
><br>
> First, thanks for your answer.<br>
><br>
> Le mer. 4 nov. 2020 à 15:50, Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> a écrit :<br>
>><br>
>><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>
><br>
><br>
> 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.<br>
> I strongly agree that the previous list of projects that you quote should stay binded to openstack cycles and should continue to rely on stable branches.<br>
> 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.<br>
><br>
>><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>
><br>
><br>
> Agreed.<br>
><br>
>><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>
><br>
><br>
> Yes, you're right, it could help us to reduce our needed maintenance and so our Oslo's activity in general.<br>
> Indeed, about 35 projects are hosted by Oslo and concerning the active maintainers the trend isn't on the rise.<br>
> 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>
><br>
>><br>
>><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>
><br>
><br>
> Yes you provided interesting observations, thanks.<br>
> It could be interesting to get feedback from other cores.<br>
><br>
>><br>
>> -Ben<br>
>><br>
><br>
><br>
> --<br>
> Hervé Beraud<br>
> Senior Software Engineer at Red Hat<br>
> irc: hberaud<br>
> <a href="https://github.com/4383/" rel="noreferrer" target="_blank">https://github.com/4383/</a><br>
> <a href="https://twitter.com/4383hberaud" rel="noreferrer" target="_blank">https://twitter.com/4383hberaud</a><br>
> -----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>
<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>