Home Original page

[python-committers] improving our code quality [my summary of the "PQM" thread]

Gustavo Niemeyer gustavo at niemeyer.net
Thu Aug 14 20:33:56 CEST 2008 
Hey Brett,

> There is also the PQM suggestion to make sure we always at least
> have some general sanity in the code base. But a PQM system would
> probably only work once the test suite is not flaky anymore as
> having some typo in a comment be rejected because test_kqueue failed
> again is not going to go over well with most people.

That's true, but these tests should actually be disabled or fixed.
There's no point in having a test that everyone finds "ok" to have
it broken.

> And that also goes for OS-specific failures on a platform I am not
> running on. Honestly the PQM system probably wouldn't be necessary
> if people just ran the entire test suite before a checkin. And if

The reason to use PQM is precisely so that your commit *does* break
when you create breakage in a platform you're not running on.  Even
though you might not care about breaking someone else's environment,
I believe it's in the best interest of everyone that this doesn't
ever happen in the main line of development.

Note that I'm playing devil's advocate here.  Just like everyone else,
I do enjoy being able to commit straight to the repository and seeing
my changes there.  On the other hand, in a complex environment where
several developers and multiple platforms are involved, the only way
to bring constant stability in is to penalize those that cause breakage.

-- 
Gustavo Niemeyer
http://niemeyer.net
More information about the python-committers mailing list