<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 13 nov. 2020 à 16:29, 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/13/20 7:05 AM, Herve Beraud wrote:<br>
> Thanks Julia for your response :)<br>
> <br>
> I propose the following migration.<br>
> <br>
> Transitioning to independent [1] model:<br>
> - oslo.i18<br>
> - oslo.log<br>
> - oslo.reports<br>
> - oslo.upgradecheck<br>
> - oslotest<br>
> - osprofiler<br>
> - stevedore<br>
> - taskflow<br>
> - tooz<br>
<br>
These all sound good to me. Honestly, anything that's not oslo.* <br>
probably should be on an independent release model since they're <br>
explicitly intended for use outside of OpenStack.<br>
<br>
> <br>
> Remaining under the cycle-with-intermediary [2] model:<br>
> - oslo.concurrency<br>
<br>
This doesn't seem particularly tied to a release. Is there a reason it <br>
should stay on the cycle release schedule?<br>
<br>
> - oslo.config<br>
> - oslo.context<br>
> - oslo.db<br>
> - oslo.limit<br>
> - oslo.messaging<br>
> - oslo.middleware<br>
> - oslo.policy<br>
> - oslo.privsep<br>
> - oslo.rootwrap<br>
<br>
Given that rootwrap is essentially in maintenance mode and will <br>
hopefully not be used once we complete the privsep community goal, I <br>
feel like this one could go independent too.<br>
<br>
> - oslo.serialization<br>
> - oslo.service<br>
> - oslo.utils<br>
> - oslo.versionedobjects<br>
> - oslo.vmware<br>
> <br>
> I'll wait a bit before proposing the migration to allow everybody to <br>
> react about the proposed lists.<br>
> <br>
> Let me know if it makes sense for you and don't hesitate to debate on <br>
> the proposed migration.<br>
<br>
The proposed changes lgtm. I think we could move a couple more as <br>
discussed above, but I'm good with it either way.<br></blockquote><div><br></div><div>I wasn't sure about oslo.concurrency and oslo.rootwrap, but I agree with you they could be moved too.</div><div><br></div><div>I'll propose the transition next week.</div><div><br></div><div>Thanks to everyone who joined this discussion.<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>
> [1] <a href="https://releases.openstack.org/reference/release_models.html#independent" rel="noreferrer" target="_blank">https://releases.openstack.org/reference/release_models.html#independent</a><br>
> [2] <br>
> <a href="https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary" rel="noreferrer" target="_blank">https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary</a><br>
> <br>
> <br>
> Le lun. 9 nov. 2020 à 17:15, Julia Kreger <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a> <br>
> <mailto:<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>>> a écrit :<br>
> <br>
> 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><br>
> <mailto:<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><br>
> <mailto:<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<br>
> independent release<br>
> >> > model [1]?<br>
> >> ><br>
> >> > I think we could consider Oslo world is mostly stable enough<br>
> to answer<br>
> >> > yes to the previous question.<br>
> >> ><br>
> >> > However, the goal of this email is to trigger the debat and<br>
> see which<br>
> >> > deliverables could be transitioned to the independent model.<br>
> >> ><br>
> >> > Do we need to expect that major changes will happen within<br>
> Oslo and who<br>
> >> > could warrant to continue to follow cycle-with-intermediary<br>
> 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<br>
> 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<br>
> on the<br>
> >> regular cycle release schedule. The same goes for other<br>
> libraries too:<br>
> >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db,<br>
> possibly also<br>
> >> things like oslo.config and oslo.context (I suspect contexts<br>
> need to be<br>
> >> release-specific, but maybe someone from a consuming project can<br>
> weigh<br>
> >> in). Even oslo.serialization could have upgrade impacts if it is<br>
> 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<br>
> independent model but more to identify which projects could be<br>
> eligible for this switch.<br>
> > I strongly agree that the previous list of projects that you<br>
> quote should stay binded to openstack cycles and should continue to<br>
> rely on stable branches.<br>
> > These kinds of projects and also openstack's services are<br>
> strongly tied to backends, their version, and available APIs and so<br>
> 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<br>
> really<br>
> >> tied to a specific release. As long as we're responsible with<br>
> 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<br>
> 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<br>
> 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<br>
> maintenance and so our Oslo's activity in general.<br>
> > Indeed, about 35 projects are hosted by Oslo and concerning the<br>
> active maintainers the trend isn't on the rise.<br>
> > So reducing the number of stable branches to maintain could<br>
> benefit us, and it could be done by moving projects to an<br>
> independent model.<br>
> ><br>
> >><br>
> >><br>
> >> I guess I don't have a strong opinion one way or another on this<br>
> yet,<br>
> >> and would defer to our release liaisons if they want to go one<br>
> way or<br>
> >> other other. Hopefully this provides some things to think about<br>
> 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>
> <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></div>