[oslo][release] Oslo's Transition To Independent
Herve Beraud
hberaud at redhat.com
Thu Nov 19 13:57:21 UTC 2020
Le ven. 13 nov. 2020 à 16:29, Ben Nemec <openstack at nemebean.com> a écrit :
>
>
> On 11/13/20 7:05 AM, Herve Beraud 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
>
> These all sound good to me. Honestly, anything that's not oslo.*
> probably should be on an independent release model since they're
> explicitly intended for use outside of OpenStack.
>
> >
> > Remaining under the cycle-with-intermediary [2] model:
> > - oslo.concurrency
>
> This doesn't seem particularly tied to a release. Is there a reason it
> should stay on the cycle release schedule?
>
> > - oslo.config
> > - oslo.context
> > - oslo.db
> > - oslo.limit
> > - oslo.messaging
> > - oslo.middleware
> > - oslo.policy
> > - oslo.privsep
> > - oslo.rootwrap
>
> Given that rootwrap is essentially in maintenance mode and will
> hopefully not be used once we complete the privsep community goal, I
> feel like this one could go independent too.
>
> > - 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.
>
> The proposed changes lgtm. I think we could move a couple more as
> discussed above, but I'm good with it either way.
>
I wasn't sure about oslo.concurrency and oslo.rootwrap, but I agree with
you they could be moved too.
I'll propose the transition next week.
Thanks to everyone who joined this discussion.
>
> >
> > [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
> > <mailto: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
> > <mailto:hberaud at redhat.com>> wrote:
> > >
> > > First, thanks for your answer.
> > >
> > > Le mer. 4 nov. 2020 à 15:50, Ben Nemec <openstack at nemebean.com
> > <mailto: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-----
> >
>
>
--
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-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201119/cfdef905/attachment-0001.html>
More information about the openstack-discuss
mailing list