Re: [python-committers] PQM?
Hey Barry, First, let me thank you for taking the energy to express many interesting points in that discussion. >> I don't have experience with PQM or something like it, but I suspect >> it doesn't scale, and the buildbots are a better approach, because >> they handle multiple platforms. (...) > - - PQM: right, doesn't scale across multiple platforms, but still valuable. > Guards against broken mainline affecting everybody. E.g. would have caught > the multiprocessing bug that delayed an earlier release affecting at least > Linux and OS X. I'm not sure I get what's the scaling issue here. It's likely that you guys have some experience that I lack, and thus are talking about an obvious issue that I'm not aware of. We're actually adopting a PQM-based approach *precisely* because we have to maintain a code base in multiple versions of the same platform, and thus can't be sure that the tests will continue working just by running the suite in our own environments. In this case PQM will help precisely because running tests locally "doesn't scale", which is why I'm a bit surprised by the straightforward agreement on the point above. What exactly is the "doesnt' scale" issue in this case? -- Gustavo Niemeyer http://niemeyer.net ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] improving our code quality [my summary of the "PQM" thread]
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 ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
Hey Martin, >> What exactly is the "doesnt' scale" issue in this case? > > I don't actually know PQM, but from what I hear, it appears that > PQM can't run tests for a single patch on all of Solaris, Linux, > Windows, and OS X before accepting it. Instead, PQM will run the > tests on the same machine it runs on itself, and only on that > machine. We actually have PQM setup to work in multiple machines for the same commit, since we have to ensure that the same source code passes all tests in a number of platform versions. I don't personally know in which platforms PQM runs. In any case, I'm not suggesting Python should use PQM-the-implementation. Maybe it's too complex for what is necessary, or too simple, or not portable enough, or whatever. At this point, I'm only trying to point out that if you want stability on platforms that differ from the local one in which a developer run the test suite on, you must block the merges that will break the other platforms. Even though a bit obvious, this idea is still not very popular nowadays because for a long time, not merging broken code meant not keeping evolving source code under revision control. This doesn't have to be true now. Developers may evolve their code in a broken way for a long time before integrating in a main line of development, and consequently without creating breakage for others, and blocking releases. -- Gustavo Niemeyer http://niemeyer.net ___ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
