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/a36f514295a4b4e6157ce69a210f653bcc4df7f2
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
>