---- On Wed, 22 Sep 2021 11:15:05 -0500 Sylvain Bauza <sylvain.bauza@gmail.com> wrote ----
Le mer. 22 sept. 2021 à 18:05, Balazs Gibizer <balazs.gibizer@est.tech> a écrit :
On Wed, Sep 22 2021 at 01:15:13 PM +0000, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-09-22 14:56:43 +0200 (+0200), Előd Illés wrote: [...]
Option 3: it is really just a temporary solution (maybe worse than Option 1), though it is probably acceptable to unblock gate on stable branches until the appropriate solution will be chosen. Also worth to emphasize that this problem doesn't only affect lower-constraints tests, but also could affect branches where we have old packages (versions) in upper-constraints.txt! [...]
Do also note that all solutions in this space are effectively temporary. When we drafted the stable branch and extended maintenance policies, we accepted that there comes a time for any job where circumstances may prevent us from being able to effectively continue running it. If the complexity of the solution outweighs the *temporary* benefits of being able to run the job for longer, it may not be worth the effort.
As the issue affects even the recent stable branches this would effectively mean we lose all the lower-constraints testing. And if later the same thing happen with one of our upper requirements then we will to lose all the testing. I think we cannot simply say that we ignore the problem by turning off the job.
While we almost certainly could come up with a non-default replacement for Zuul's standard tox job which allows us to use specific versions of tox, virtualenv, pip, setuptools, et cetera, that added complexity does not come for free. It has a maintenance cost which extends far into the future. Also think back on the times when we've reached for the "easy" solution of pinning such tools in other frameworks like DevStack: everyone's in a rush to stop the bleeding and get back to testing, but nobody cares about fixing the underlying issue and so such things end up pinned for years until that pinning breaks something else because we're blind to all the bitrot around us.
And then there's the fact that while we can "fix" things this way in CI jobs, these are ultimately tools for our developers which we just happen to also be able to run in the CI system, not the other way around. Pinning setuptools in the tox jobs does not solve this for developers running tox locally on their own systems. Are we going to start providing them with a list of specific versions of these tools which we're only able to test with, substantially increasing the complexity of setting up local dev environments and making it even harder for newcomers to contribute to the project?
The stable branch policy is a set of guidelines and suggestions, not an unbreakable covenant. It's there to help us make sound choices under normal circumstances, but we should not be afraid to come to a collective decision about making policy exceptions in unusual situations such as this one.
Does it mean you suggest bumping the decorator dependency to 4.0.0?
-- Jeremy Stanley
I have to say fungi made great points. While option 2 has some ideal, option 1 seems the most pragmatic and won't divert us with developing efforts for getting there (AFAIK, we don't yet have a working solution for option 2). Also, I don't know for all distros but the one I know doesn't use our lower constraints but rather redefine the dependencies by what they currently support. So, I'm even not sure bumping our lower dep here would create an issue for them if we tell them it's a minor release. Operators, thoughts about it ?
As per TC checks with distro/package maintainers on l-c usage, it is found that only Debian uses it and others do not care about it even on master branch[1]. I am also on the side of dropping the l-c from stable branches as soon as they are created instead of waiting for the broken gate and spend time on that where we know that they are hardly being used. As Fungi mentioned, TC has updated the PTI also mentioning it clearly that testing the l-c is all up to project decisions and it is totally fine to drop them (many projects already dropped it from stable) [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019877.h... -gmann