[neutron] Bumping of requirements on RDO before bumping them on Neutron

Sean Mooney smooney at redhat.com
Thu Feb 2 11:14:30 UTC 2023


On Thu, 2023-02-02 at 16:19 +1100, Tony Breeds wrote:
> On Wed, 1 Feb 2023 at 04:06, Elvira Garcia Ruiz <egarciar at redhat.com> wrote:
> > 
> > Hi Neutrinos!
> > 
> > RDO folks proposed that, in order to be able to correctly build CI
> > gates for testing, it would be nice if we tried to update the
> > neutron-distgit requirement file when we want to update the minimal
> > version of a dependency before merging it on our repository.
> > This would allow them to realize whether they need or not to update
> > any Fedora package. In order to do that, we just need to send a small
> > commit to their repository [0]. You can use your GitHub account for
> > the login.
> 
> Hello,
>     Actually I think this falls on RDO's shoulders to handle.  There
> are, or at least were,  jobs in RDO that watch the requirements repo
> for constraint updates and ensure that they're reflected in RDO
> packaging.  It shouldn't be too hard to trigger a similar change to
> the specfile when requirements.txt is updated.
> 
> Said job could even vote -1 if it encountered a situation where the
> minimum specified in requirements.txt is newer than the current
> version available in RDO. As a bonus it wouldn't even be Neutron
> specific!
as a thrid party job sure it should not be able to block the patch form merging.
> 
> It'd be kinda cool to see other distros do similar.
ya i dont think it would be correct to give RDO special treatment
its ment to be a downstream/midstream repackging of the upstrream code base
it should not impact the upstream developpment and i do not agree that we should have to bump the
RDO dist-gits before bumping merging a change to any project.

there is automation to sync uperrconstraits to rdo in some form which proposes patches
to rdo whne a new lib version is released. im sure similar automation could be done for the requirements
file if there is a min version bump. but i dont think any of this should fall on upstream developers
or core teams to do.
> 
> Yours Tony.
> 




More information about the openstack-discuss mailing list