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-inte... Le lun. 9 nov. 2020 à 17:15, Julia Kreger <juliaashleykreger@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@redhat.com> wrote:
First, thanks for your answer.
Le mer. 4 nov. 2020 à 15:50, Ben Nemec <openstack@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-----