Open Stack

Sounds super reasonable to me!

-Julia

On Fri, Nov 13, 2020 at 5:07 AM Herve Beraud <hberaud at redhat.com> wrote:
>
> Thanks Julia for your response :)
>
> I propose the following migration.
>
> Transitioning to independent [1] model:
> - oslo.i18
> - oslo.log
> - oslo.reports
> - oslo.upgradecheck
> - oslotest
> - osprofiler
> - stevedore
> - taskflow
> - tooz
>
> Remaining under the cycle-with-intermediary [2] model:
> - oslo.concurrency
> - oslo.config
> - oslo.context
> - oslo.db
> - oslo.limit
> - oslo.messaging
> - oslo.middleware
> - oslo.policy
> - oslo.privsep
> - oslo.rootwrap
> - oslo.serialization
> - oslo.service
> - oslo.utils
> - oslo.versionedobjects
> - oslo.vmware
>
> I'll wait a bit before proposing the migration to allow everybody to react about the proposed lists.
>
> Let me know if it makes sense for you and don't hesitate to debate on the proposed migration.
>
> [1] https://releases.openstack.org/reference/release_models.html#independent
> [2] https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary
>
>
> Le lun. 9 nov. 2020 à 17:15, Julia Kreger <juliaashleykreger at gmail.com> a écrit :
>>
>> Top posting because I'm a horrible person.
>>
>> Anyway, I think moving oslo to independent makes lots of sense, at
>> least to me. The key I think is to have the ability to backport and
>> release a patch/revisin/fix release if there is a major issue, but the
>> obligation to backport or even set a foundation to do so is a whole
>> other matter.
>>
>> My overall feeling, for something as stable as the oslo libraries,
>> that cycle-with-intermediacy path may just end up being a frustrating
>> headache, that is if the team feels confident and actively manages
>> their own releases of the various libraries. Also, Under the existing
>> model and policy of the release team, they would basically end up back
>> where they started if the libraries failed to release multiple times,
>> which may not make sense for stable libraries.
>>
>> Anyway, just my $0.02.
>>
>> -Julia
>>
>> On Fri, Nov 6, 2020 at 2:04 AM Herve Beraud <hberaud at redhat.com> wrote:
>> >
>> > First, thanks for your answer.
>> >
>> > Le mer. 4 nov. 2020 à 15:50, Ben Nemec <openstack at nemebean.com> a écrit :
>> >>
>> >>
>> >>
>> >> On 11/4/20 7:31 AM, Herve Beraud wrote:
>> >> > Greetings,
>> >> >
>> >> > Is it time for us to move some parts of Oslo to the independent release
>> >> > model [1]?
>> >> >
>> >> > I think we could consider Oslo world is mostly stable enough to answer
>> >> > yes to the previous question.
>> >> >
>> >> > However, the goal of this email is to trigger the debat and see which
>> >> > deliverables could be transitioned to the independent model.
>> >> >
>> >> > Do we need to expect that major changes will happen within Oslo and who
>> >> > could warrant to continue to follow cycle-with-intermediary model [2]?
>> >>
>> >> I would hesitate to try to predict the future on what will see major
>> >> changes and what won't. I would prefer to look at this more from the
>> >> perspective of what Oslo libraries are tied to the OpenStack version.
>> >> For example, I don't think oslo.messaging should be moved to
>> >> independent. It's important that RPC has a sane version to version
>> >> upgrade path, and the easiest way to ensure that is to keep it on the
>> >> regular cycle release schedule. The same goes for other libraries too:
>> >> oslo.versionedobjects, oslo.policy, oslo.service, oslo.db, possibly also
>> >> things like oslo.config and oslo.context (I suspect contexts need to be
>> >> release-specific, but maybe someone from a consuming project can weigh
>> >> in). Even oslo.serialization could have upgrade impacts if it is being
>> >> used to serialize internal data in a service.
>> >
>> >
>> > 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.
>> > 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.
>> > 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.
>> >
>> >>
>> >> That said, many of the others can probably be moved. oslo.i18n and
>> >> oslo.upgradecheck are both pretty stable at this point and not really
>> >> tied to a specific release. As long as we're responsible with any future
>> >> changes to them it should be pretty safe to make them independent.
>> >
>> >
>> > Agreed.
>> >
>> >>
>> >> This does raise a question though: Are the benefits of going independent
>> >> with the release model sufficient to justify splitting the release
>> >> models of the Oslo projects? I assume the motivation is to avoid having
>> >> to do as many backports of bug fixes, but if we're mostly doing this
>> >> with low-volume, stable projects does it gain us that much?
>> >
>> >
>> > Yes, you're right, it could help us to reduce our needed maintenance and so our Oslo's activity in general.
>> > Indeed, about 35 projects are hosted by Oslo and concerning the active maintainers the trend isn't on the rise.
>> > So reducing the number of stable branches to maintain could benefit us, and it could be done by moving projects to an independent model.
>> >
>> >>
>> >>
>> >> I guess I don't have a strong opinion one way or another on this yet,
>> >> and would defer to our release liaisons if they want to go one way or
>> >> other other. Hopefully this provides some things to think about though.
>> >
>> >
>> > Yes you provided interesting observations, thanks.
>> > It could be interesting to get feedback from other cores.
>> >
>> >>
>> >> -Ben
>> >>
>> >
>> >
>> > --
>> > Hervé Beraud
>> > Senior Software Engineer at Red Hat
>> > irc: hberaud
>> > https://github.com/4383/
>> > https://twitter.com/4383hberaud
>> > -----BEGIN PGP SIGNATURE-----
>> >
>> > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
>> > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
>> > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
>> > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
>> > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
>> > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
>> > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
>> > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
>> > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
>> > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
>> > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
>> > v6rDpkeNksZ9fFSyoY2o
>> > =ECSj
>> > -----END PGP SIGNATURE-----
>> >
>>
>
>
> --
> Hervé Beraud
> Senior Software Engineer at Red Hat
> irc: hberaud
> https://github.com/4383/
> https://twitter.com/4383hberaud
> -----BEGIN PGP SIGNATURE-----
>
> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
> v6rDpkeNksZ9fFSyoY2o
> =ECSj
> -----END PGP SIGNATURE-----
>