Ivan Pozdeev via Python-Dev writes:
> Possessive and obstructive behavior like Victor describes below is
> incompatible with the bazaar model of development (=a model where
> the dev team accepts contributions from a wide range of people).
True, but Python *modules* have frequently followed a not-exactly-
benevolent dictator model.[1] As mentioned by several contributors
(including some who have expressed adverse opinions on the behavior in
this case), the Decimal module is composed of extremely high-quality
code, which has also been revised to provide a huge performance
enhancement. Purely obstructive behavior is IMO relatively easy to
identify, but it can be quite difficult to distinguish a very high
quality standard from possessiveness. For the team members and
occasional contributors, it can be very satisfying to clear a high bar
after much effort. (But then, I have a PhD so I may not be a good
person to testify on this.)
Within modules, I think there is plenty of room for a wide variety of
attitudes toward quality of code, especially given the branching
capability of our VCS: from "move fast and break things" (and fix them
even faster) to "every commit should be release-candidate-ready". (In
some cases, such as the interpreter itself, the SC will want to
mandate a level of QA, and of course any such standard will vary by
branch and over the release cycle; that kind of situation is included,
just not project-wide.)
> As a result, both sides lose: users don't get the features/bugfixes
> that they want (since their contributions are being rejected for no
> good reason), maintainers don't get contributions (since their
> requirements are unreasonable or outright impossible to meet), both
> sides waste a lot of time unproductively in the process.
Sure, but there are also cases where extremely high standards lead to
a small, tight-knit, and highly productive team. As a general policy,
I hope the Steering Council will lean hard in the direction of
inclusiveness, but by the same token we can include a few teams that
choose to impose extremist standards on *themselves*.
Of course, giving the benefit of doubt to the Decimal maintainer,
sometimes extreme quality demands will conflict with project-wide
efforts such as Victor's refactorings. I've dealt with such
refactorings in the past: they can be a real PITA to other developers
as the code they're working with changes out from under them. As
Victor describes his work, it was worthwhile in terms of performance
improvement, of very high quality in terms of regression testing for
the particularly demanding Decimal module, and (I guess) not touching
on the internals of the Decimal module (ie, the changes seem to be in
boilerplate code for interfacing with the core code). In such cases
it's not obvious where the burden of resolving the conflict *should*
fall: with the "outsider" mucking around in "everybody else's" code,
or with the individual maintainers, to keep their code up with best
practices in the project. I don't see a general principle here. I
think that when the parties involved don't negotiate a settlement
themselves, this decision needs to be made on a case by case basis.
> For a testimony from someone with more experience at maintaining
> than me, see e.g.
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s03.html
> and
r >
http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ar01s11.html .
I don't really trust Eric on these issues. He has a very spotty
history, himself, and in personal interactions I've seen him to be
both quite open to personal criticism and rather hypocritical (in the
literal sense of not thinking much about it and just accepting the
natural human feeling that "I'm a good guy, I'm probably not wrong!")
And in fact, both of those selections expose internal contradictions
of the models ESR espouses. I agree, those are seminal models, but as
the word "seminal" suggests, they needed a lot of development.
> AFAICS, Python uses the bazaar model as its development
> principle. As such, Stefan could be suspended even earlier, at one
> of the instances that Victor described, -- for sabotaging the
> project.
In this case, I tend to agree with you *in theory* based on what has
been stated (and mindful of the fact that Stefan has said very
little), but I could only advocate action if I knew *much* more of the
facts. But I don't see how this could possibly be usefully enunciated
as policy. It's too fact-dependent.
> On 10.10.2020 16:46, Victor Stinner wrote:
> > I was never comfortable with the fact that other contributors
> > must also avoid Stefan (missing stair) and so don't attempt to
> > touch the decimal module. I would prefer greater collaboration on
> > a stdlib module, because we have to distribute the maintenance to
> > make Python sustainable.
I think "comfortable" is an excellent word here. I don't think that
the Steering Council can make sufficie
