> The community has been very capable if an external change (Death of

> Python 2.7, SQLAlchemy 2.x, eventlet EoL, ....)
> forced some reaction or adaption. But does it really require some
> external force for some kind of modernization?

I'm isolating this for a specific reason: many of the items listed here were driven by the same major contributors (human and corporate) to the community, and/or are in progress. For instance, the eventlet migration still does not have a finalized plan[0] and the primary drivers right now are developers from RedHat as well as a single GR-OSS developer we contributed to help improve eventlet in the short term. When describing this to my boss; I told him I'm incredibly proud that GR-OSS is participating in this work, because so few contributing companies are willing to do this invisible work -- but the sad thing is, eventlet eol is one of a large number of things that needs doing -- and there aren't many people to do it.

This email thread highlights many of those other issues which need addressing; but are missing a significant portion: a call to action and real work to make them happen.

There are several ways you help change this:

1) Don't like how the project is being run from a technical perspective? Run for the TC -- there certainly is a need for volunteers. Try to make change happen. Governance is not easy and there are hundreds of people with different opinions about what direction "forward" is -- and it's a lot more work than just adding and removing python versions from platform documents.

2) Do a proof of concept in a smaller project. I'd personally be willing to help you gain consensus on implementing (for instance) some type hints on Ironic. I can't promise the whole Ironic team would agree; but the point is the easiest way to influence change in OpenStack is to show willingness to do the work. For SQLA 2.0 migration, for instance, it was obvious there were some members of the community who worked towards it, with urgency, even pulling forward projects that are now inactive to function with SQLA 2.0.

3) Advocate inside your organization for more upstream contribution; either in the form of your time or additional upstream contributors. A recent paper[1] out of Harvard Business School says 96% of the demand-side value is created by only 5% of OSS developers. Everyone who has a leadership position at a company that uses or contributes to OSS has an obligation to advocate to help close these gaps.

I'm not going to break down the original email point by point, but generally: yes, there are things that OpenStack are behind on -- but emails to the mailing list and consensus aren't the solution. The solution is more people contributing to solve these problems -- especially in traditionally under-resourced teams such as QA, oslo libraries, and smaller projects on the verge of inactivity. Jeremy said (paraphrased) that we are OpenStack; rather than asking why OpenStack is not pushing forward, we should be asking ourselves why we aren't pushing forward. I agree with him. I also agree with the OP which asserts that we have clear technical improvement opportunities. What's stopping you from pushing them forward?

Thanks,

Jay Faulkner

OpenStack TC Chair & Ironic PTL

Open Source Developer, G-Research OSS

0: https://review.opendev.org/c/openstack/governance/+/902585

1: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4693148

On Wed, Feb 14, 2024 at 2:21 AM Christian Rohmann <christian.rohmann@inovex.de> wrote:

Thanks for starting a discussion about the (Python) stack as a whole and
not just making this about using Python 3.9 vs. 3.12....

OpenStack is a well established cloud software stack and just like the
Python interpreter and whole ecosystem is relies on,
it should embrace new capabilities and not just move if there is an
unavoidable breaking change.

Subjectively there has been quite some developer drain or let's say the
amount of patches by new developers seems
lower than years ago. Quite a few projects died with not replacement.
The community has been very capable if an external change (Death of
Python 2.7, SQLAlchemy 2.x, eventlet EoL, ....)
forced some reaction or adaption. But does it really require some
external force for some kind of modernization?
Why is OpenStack is not pushing ahead in and out of itself? For the sake
of one's own quality standards, but also
to ensure the whole ecosystem remains vital and and attractive to new
new developers?

On 13.02.24 13:27, Niklas Schwarz wrote:
> A modern and up to date static code analysis:
> Currently flake8 and pylint are used both of which are modern analysis
> tools. But their configuration is in my opinion
> not up to date. Lets have a look at the configuration of the
> neutron-lib [6]. As seen a lot of rules are disabled
> by the configuration and are needed at the current moment at the state
> of the project. In addition some rules
> need to be adjusted such as the line length (80 characters is a very
> aggressive limit and on most modern
> displays a line length of 100 to 120 can fit without any problems,
> personal opinion).
> The adjustment of the static code analysis besides opinionated rules
> will lead me to my third point to modernize
> the Python stack used
> Introduce type annotations
> [...]
> The type hints can and in in my experience will reduce the
> introduction of
> bugs (accessing members or calling methods, no logical bugs) and will
> shorten the time to develop a new
> feature or fix a logical bug and do not run in runtime exceptions.

I can only second Niklas' reference to the PEP 484 ([2]) and its rationale:

> This PEP aims to provide a standard syntax for type annotations,
> opening up Python code to easier static analysis and refactoring,
> potential runtime type checking, and (perhaps, in some contexts) code
> generation utilizing type information.
> Of these goals, static analysis is the most important. This includes
> support for off-line type checkers such as mypy, as well as providing
> a standard notation that can be used by IDEs for code completion and
> refactoring.
>
an this is from 2014, so about 10 years ago.

While unit and functional tests allow people to move faster in writing
their code,
be it a bugfix or feature as they quickly see if their code breaks
stuff. But having static code analysis as a first line of defense is a must.
Continuing to allow more un-typed variables, references and interfaces
limits the good those kind of tools can do.

If I may quote an reply to an old post to the ML ( [1]) about the
introduction of "black" formatter:

On 18.4.19 19:04, Clint Byrum wrote: :

> The main value is that using an automatic formatter will ultimately lead
> to less wasted test runs, less wasted developer time, and better diffs
> with less conflicts later.
>
> So while I appreciate the desire to not rock the boat, it might be that
> the boat would go faster after some dead weight is dropped overboard,
> and that new energy is applied to forward progress instead of "darn it,
> now I have to think about how to fit this into 80 chars and parenthesis
> and ..."
>
> Basically, weigh the one time cost vs. the ongoing savings, rather than
> considering them separately.

Agreeing on a set of rules then set in stone (or rather the config of
formatter, linters and static code analysis tools)
increases the quality of the code, makes it more approachable to new
devs and allows reviewers to focus more on the
logic and functional part of submitted code. And what's the downside of
moving into this direction really?

* A big initial reformatting commit that makes it harder to then
backport changes to older releases?
* Introducing types to older code and identifying issues this way?
* Static code analysis throwing lots of warnings?

Regards

Christian

[1]
https://lists.openstack.org/pipermail/openstack-discuss/2019-April/005364.html
[2] https://peps.python.org/pep-0484/#rationale-and-goals