On Wed, Apr 10, 2024 at 10:09 AM <smooney@redhat.com> wrote:
On Wed, 2024-04-10 at 14:37 +0200, Sven Kieske wrote:
Am Montag, dem 08.04.2024 um 14:54 +0100 schrieb smooney@redhat.com:
the tone that Sven has been taking in this thread has been often bordering on insuting if not mearly condesending.
@sven for people that care deeply about the quality of software we produce and has advocated for using tools like mypi, auto formnating, code modreisers liek pyupgrade ectra the way you are approching this is hurting the efforts to maintain and moderise our codebase more then its helping.
we have been having dissusion like this for years and we are making incremenal impormbet but any kind of browbeating with stats just reads as trying to bully people with data instead of takeing the time to have a calm, reasoned converstation that empathises with the others invovled.
Hi Sean,
I'm sorry that I apparently insulted you, that was really not what I wanted to do. I certainly have learned a lot about openstack from your insights posted to this mailing list in the past.
I know there have been previous discussions about these topics and that there are gradual improvements. I also think only incremental improvements are possible in a large project like openstack.
It was not my intend to "bully" anyone with data. But it was raised the question between the lines if there is any advantage to static typing at all. I just replied with a study that shows that at least under some circumstances, yes there are advantages.
I understand and think that it's good that people like me who demand change need of course put in the work and show that change is beneficial at all.
I just try to do that.
Sorry again if my tone went over the line, arguments around coding style and which tools to use somehow often can become very heated.
no worreis i can get pretty pasionate about the things i care about too. software quality is one of them. i personally find value in type hints in python and use them for new code i write in general i konw others find less value in them but thats where indvigual projects can show leadership and experiment and then report back.
To piggyback on this, this topic was discussed yesterday during Neutron vPTG sessions, and the team decided to try the following: - pick neutron-lib for typing adoption; reasons for neutron-lib are: it's our central python API component and consuming projects could benefit from typing both for analysis and as documentation, plus it's relatively simple; - Miro T will build infrastructure (tox, docs etc.) to start adoption; - we'll then proceed adopting typing there gradually and see if this is a success; - Eventually, we may want to step up for other repos, depending on results.
without opening the holy war of black vs pep8 that is another example of where some project have adopted it as a code formater and other have not both for vaild reasons.
if we were startign openstack from scratch today we would likely use many of these tools its harder to adopt them in existing projects.
i dont really agree with the main pushback (the impact on backports) but that does not mean indeivugal project cant adopt these tools
the sdk team felt the benifit outweighted any cost
https://github.com/openstack/openstacksdk/commit/a36f514295a4b4e6157ce69a210...
the imporant thing to rememeber is that the indivgual projects are empored to make some of these decisiosn by them seleve and dont need tc approval to do so.
we do have some rules around the project testing interfance that all offical project should follow
https://github.com/openstack/governance/blob/master/reference/pti/python.rst but that still leave a lot of flexablity for teams to evolve there workflow.
its take a few years but for nova we have impoved the workflow (IMO) by adotpting precommit as an optional way to run many of the simple/fast styple checks https://github.com/openstack/nova/blob/master/.pre-commit-config.yaml while also ensuring that those who dont want to use pre-commit can continue to use tox https://github.com/openstack/nova/blob/master/tox.ini#L101-L132
we have been more conservitive then i would personally like but we have at least been open to the discussion adn if someone was willing to do the work trying to make these improments.
if you approch it form that perspective i think you will much more eaislly which reminds me i need to rebase https://review.opendev.org/q/topic:%22sphinx-lint%22 to enable sphinx lint properly...
Kind regards