Re: [python-committers] [Python-Dev] next beta
> > I'll put my hand up for doing the Windows build as well (the x64 > > buildbot has all the necessary bits and pieces installed). I > > know some HP people that I could rope in to install the resulting > > IA64 build and run rt.bat. > Notice that we both look for somebody to build the next 2.6/3.0 > betas (see the subject), and the 2.5.3 rc and final release > (assuming Anthony still has that plan). I'd like to offer my Win2k8 x64 colo box for building Python installers. It's a Hyper-V instance with four cores, 4GB of RAM and plenty of disk space, and has just about every Microsoft-oriented development tool installed produced this decade (inc. Itanium compilers). So, ideally, any committer that's interested in being able to produce the official Python binaries can drop me a note and I'll give them remote access. That way we've got a single 'build server' for producing releases, as well as multiple people with the capacity to perform such builds. I'm probably biased because it's a freakin' expensive colo and I'm severely under-utilising the box (host is an 8-core 8GB monster), but I'd argue that a nominated build server is more desirable for official releases than someone's laptop. Thoughts? (Even if we don't go down this path, if other developers would like remote access to the box just drop me an e-mail. I specifically acquired it to 'donate' to Python-oriented activities; no-one else has access to it.) Trent. ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 12, 2008, at 2:44 PM, Martin v. Löwis wrote: I am planning to offer a single file patch for 2.3 and 2.4. As far as one more 2.5 release, I don't think there's going to be many changes to the 2.5 branch between now and 2.6/3.0 final - although if there is, we'll obviously have to do another release. I would like to establish a tradition where, after some final bug fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch). I'm not sure I agree with this policy. Can you elaborate on /why/ you want this? Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. Why is that qualitatively different than a security fix? All the same conditions apply. An alternative would be to keep all infrastructure up and running, but that is infeasible. Or to adopt tools that help improve reliability. I'm not convinced that the buildbots really do that. A PQM-style approach, while more of a pain for developers because of the serialized landings, would definitely improve things, and there's not nearly as much infrastructure involved to keep humming for old releases. PQM isn't perfect, but I do believe it would help. I understand that we're a volunteer organization, and that our resources are limited. I'm also wary about siphoning off those limit resources right now for working on other than 2.6 and 3.0, but I'm not sure that this policy really buys us much there. E.g. with this policy you'll need a release cop to patrol commits and back out non-security fixes right away. That's not necessary. When I made 2.3.7 and 2.4.5, I went through the complete log, and posted a list of patches that I wanted to revert. This was little effort, and I'm sure it would have been even less effort if people had known that 2.4.x is a closed branch. I'm glad it wasn't much effort. Would you propose using technological means to close the branch? It's much more work to revert such changes whenever we get around to doing the release. Seems like it could be /more/ work with this policy. It wasn't really that much work - there were little non-security patches, and they were easily identifiable from the commit message. I do agree that we need to be very careful about introducing new features, but I think non-security patches can be okay. They aren't, as they don't get sufficient testing. Again, I don't think that's qualitatively much different for security patches. We may manually test them, inspect them, rely on vendors to have tested them, but they don't go through the Q/A process we enforce for our active branches. It's demoralizing to have one's patches backed out. Besides, we still have downstream vendors that are maintaining and releasing Python 2.4; does this mean they're out of luck for bug fixes or they have to roll their own? I've talked to the downstream vendors, and they really want security patches for a long time, above all. They are fine with maintaining their own patches (which they do, anyway). Would a policy of security-patches-only have any effect on vendors sharing fixes with us? By that I mean, if 2.4 were open to non- security patches, would they be more or less willing to feed them upstream, where we could, if someone were motivated, port them forward? We're on an 18 month release schedule, which is a long time to wait, so I'm not in favor of an arbitrary date for cutting off "mere" bug fixes. Rather, I'd like to see a policy (but not a promise) of supporting two releases at a time. I think this requires more resources than we have - especially with your way of counting: Thus, when 2.6 is released, we would stop support for all but critical security fixes for 2.4, but we could (not will) still release bug fixes for 2.5. And of course, we'll support 2.6/3.0 while 2.7/3.1 is being developed. So that's *three* branches that we need to maintain, right: 2.5, 2.6, and 3.0. Once 3.1 is released, I supposed it's even *four* branches: 2.6, 2.7, 3.0, and 3.1. That means that every change must be committed/merged four times, you need to run the test suite four times, and so on. Depending on the nature of the bug fix, you also need to keep the specifics of the four branches in mind. I don't think our committers will accept such a work load - which means that some patches don't get backported (arbitrarily, depending on how relevant the committer views that policy). Let me emphasize that I'm not suggesting our committers do this. I'm suggesting that
Re: [python-committers] PQM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 6:41 PM, Antoine Pitrou wrote: Le mercredi 13 août 2008 à 18:33 -0400, Barry Warsaw a écrit : Or to adopt tools that help improve reliability. I'm not convinced that the buildbots really do that. A PQM-style approach, while more of a pain for developers because of the serialized landings, would definitely improve things, and there's not nearly as much infrastructure involved to keep humming for old releases. PQM isn't perfect, but I do believe it would help. What is a "PQM-style approach"? PQM = Patch Queue Manager Basically, it's a robot that controls commits to the trunk. Nothing lands in the trunk without getting through PQM first. PQM serializes changesets so that they must apply cleanly with no conflicts, and pass the entire test suite. There could be other conditions, e.g. that it lints cleanly, has no whitespace issues, etc. If any of the set of conditions fail, the changeset does not land. This means that the trunk is always in a releasable state, and we avoid the problems I run into all the time now, where we have red buildbots on or near release date. I would dearly love to be able to spin a release at any time and have a high degree of confidence that what I'm releasing is stable. There's a specific implementation of PQM based on the Bazaar revision control system, available here: https://edge.launchpad.net/pqm PQM is not perfect, nor is it a perfect fit for us. For example, we have buildbots that run on multiple platforms, while PQM runs on a single platform. So a vanilla PQM could still miss changes that break only on a specific operating system. It also doesn't help at all for bugs not covered by the test suite (well, buildbots don't help there either ;). PQM also introduces delays on trunk landing because it serializes commits. So when things get backed up, it might take a while for your branch to land on the trunk. PQM wouldn't replace the buildbots, but it would greatly improve the quality of the development branches, IMO. The buildbots would still be useful to ensure cross-platform quality. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKNoP3EjvBPtnXfVAQIrdwP+I9Cj7uBl+Ux9ioDd+Xc2KXCcF0hXRqpj z4XfUdZeWlUQdUoNspj/mzl9Q/zVz4wyTUmmDV3nH9a5qd6vGAnFvOZHLwpipDE2 NYISJYVWlYp71ljANJ/sWoywAc8Lj/AaD2l532S8RC4JPf53MNlIyB3CtIpDq315 ZMqS3RSRP10= =5qLh -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
>> Because there won't typically be sufficient testing and release >> infrastructure to allow arbitrary bug fixes to be committed on the >> branch. The buildbots are turned off, and nobody tests the release >> candidate, no Windows binaries are provided - thus, chances are very >> high that a bug fix release for some very old branch will be *worse* >> than the previous release, rather than better. > > Why is that qualitatively different than a security fix? All the same > conditions apply. No. The problem being fixed is completely different. For a security fix, it is typically fairly obvious what the bug being fixed is (in particular, if you look at the recent ones dealing with overflows): the interpreter crashes without the patch, and stops crashing (but raises an exception instead) with the patch. For regular bug fixes, it is much more difficult to see whether the behavior being changed was a bug. They typically "merely" change the behavior A to behavior B, along with a claim that behavior A is a bug, and behavior B is correct. Even if that is true, there is still a chance that applications relied on behavior A, and break. OTOH, for an interpreter crash, it is highly unlikely that existing applications rely on the crash. For example, in the 2.4 branch, among the patches I rolled back, was r53001. This adds string.strip to the lookup of logging handlers. It might be "better" to do that (and perhaps even correspond with the documentation), but still, it might break applications which had leading or trailing spaces in their handlers names. >> That's not necessary. When I made 2.3.7 and 2.4.5, I went through the >> complete log, and posted a list of patches that I wanted to revert. >> This was little effort, and I'm sure it would have been even less effort >> if people had known that 2.4.x is a closed branch. > > I'm glad it wasn't much effort. Would you propose using technological > means to close the branch? They are still open for security patches (well, 2.4 is; under my proposed policy, 2.3 isn't anymore). If people think it's desirable, we could rename the branch, or we could enforce a certain keyword (e.g. "security") in the commit messages. > Again, I don't think that's qualitatively much different for security > patches. We may manually test them, inspect them, rely on vendors to > have tested them, but they don't go through the Q/A process we enforce > for our active branches. Due to the reliance on inspection, it is *particularly* important that there are only few of them, and that those are all local. > Would a policy of security-patches-only have any effect on vendors > sharing fixes with us? By that I mean, if 2.4 were open to non-security > patches, would they be more or less willing to feed them upstream, where > we could, if someone were motivated, port them forward? I do think that vendors will continue to provide patches. They want to get rid of them to reduce their overhead, eventually, and it doesn't really matter that much that they get rid of them for the current branch (as they have done all the hard work there already). Efforts grow when you need to forward-port it, in which case you do want to contribute it upstream (in the hope of at least partially offloading the effort to a regular Python contributor). > Let me emphasize that I'm not suggesting our committers do this. I'm > suggesting that if a specific committer is motivated to fix a > non-security bug in an older release, they would have to accept this > responsibility. Maybe it'll never happen because no one really cares > enough. But a policy against it would /prevent/ it even if there was > motivation to do it. I don't like the arbitrariness that this will produce. >> I think this is an illusion. When did you last commit something to the >> trunk, and forward-ported it to the 3.0 branch? When did you last run >> "svnmerge avail"? Porting patches between 2.6 and 3.0 is anything but >> trivial. > > I'll concede that it's very difficult. Indeed. I just added s* to both 2.6 and 3.0, and it took me two days to port it from 2.6 to 3.0 (just because 3.0 was using the buffer interface in so many more places). Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
> PQM serializes changesets so that they must apply cleanly with no > conflicts, and pass the entire test suite. What platform would it run the test suite on? Presumably the same one I tested on before I submitted the patch :-). I think this works if you're a Linux development shop, but perhaps not as well for Python. Bill ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
On Wed, Aug 13, 2008 at 3:33 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: [SNIP] >> An alternative would be to keep all infrastructure up and running, >> but that is infeasible. > > Or to adopt tools that help improve reliability. I'm not convinced that the > buildbots really do that. A PQM-style approach, while more of a pain for > developers because of the serialized landings, would definitely improve > things, and there's not nearly as much infrastructure involved to keep > humming for old releases. PQM isn't perfect, but I do believe it would > help. > What is a "PQM-style approach" to releases? -Brett ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
On Wed, Aug 13, 2008 at 4:03 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Aug 13, 2008, at 6:41 PM, Antoine Pitrou wrote: > >> Le mercredi 13 août 2008 à 18:33 -0400, Barry Warsaw a écrit : >>> >>> Or to adopt tools that help improve reliability. I'm not convinced >>> that the buildbots really do that. A PQM-style approach, while more >>> of a pain for developers because of the serialized landings, would >>> definitely improve things, and there's not nearly as much >>> infrastructure involved to keep humming for old releases. PQM isn't >>> perfect, but I do believe it would help. >> >> What is a "PQM-style approach"? > > PQM = Patch Queue Manager > > Basically, it's a robot that controls commits to the trunk. Nothing lands > in the trunk without getting through PQM first. PQM serializes changesets > so that they must apply cleanly with no conflicts, and pass the entire test > suite. There could be other conditions, e.g. that it lints cleanly, has no > whitespace issues, etc. > Ah, OK. > If any of the set of conditions fail, the changeset does not land. This > means that the trunk is always in a releasable state, and we avoid the > problems I run into all the time now, where we have red buildbots on or near > release date. I would dearly love to be able to spin a release at any time > and have a high degree of confidence that what I'm releasing is stable. > Well, it would definitely catch those changes that manage to break ALL the buildbots, but those that only break on the platforms that the developer is not on might just cause pain. > There's a specific implementation of PQM based on the Bazaar revision > control system, available here: https://edge.launchpad.net/pqm > Why am I not surprised that bzr has support for something you are suggesting? =) > PQM is not perfect, nor is it a perfect fit for us. For example, we have > buildbots that run on multiple platforms, while PQM runs on a single > platform. So a vanilla PQM could still miss changes that break only on a > specific operating system. It also doesn't help at all for bugs not covered > by the test suite (well, buildbots don't help there either ;). > > PQM also introduces delays on trunk landing because it serializes commits. > So when things get backed up, it might take a while for your branch to land > on the trunk. > There is also the shift in development style to larger patch sets (assuming your version control system supports patch sets) instead of a lot of incremental commits to the trunk since you might end up with a cascading failure of your commits if you were dependent on an earlier one fails and thus all your subsequent checkins will be rejected. > PQM wouldn't replace the buildbots, but it would greatly improve the quality > of the development branches, IMO. The buildbots would still be useful to > ensure cross-platform quality. Well, another option is to flesh out ``make check`` such that it runs more sanity checks and makes sure the entire test suite is run and passed before a commit is done, basically doing what you are suggesting, but on a local level. -Brett ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
Le mercredi 13 août 2008 à 18:33 -0400, Barry Warsaw a écrit : > Or to adopt tools that help improve reliability. I'm not convinced > that the buildbots really do that. A PQM-style approach, while more > of a pain for developers because of the serialized landings, would > definitely improve things, and there's not nearly as much > infrastructure involved to keep humming for old releases. PQM isn't > perfect, but I do believe it would help. What is a "PQM-style approach"? ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
On Wed, Aug 13, 2008 at 8:49 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Well, another option is to flesh out ``make check`` such that it runs > more sanity checks and makes sure the entire test suite is run and > passed before a commit is done, basically doing what you are > suggesting, but on a local level. In my "testing" branch, I have added support for this in "make check". > > -Brett > ___ > python-committers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-committers > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
Barry Warsaw wrote: PQM = Patch Queue Manager Basically, it's a robot that controls commits to the trunk. Nothing lands in the trunk without getting through PQM first. PQM serializes changesets so that they must apply cleanly with no conflicts, and pass the entire test suite. There could be other conditions, e.g. that it lints cleanly, has no whitespace issues, etc. Personally I'm totally against any kind of tool like PQM for general development. Issues due erroneous check-ins are a social problem. I strongly believe that social problems can't be solved by a system like PQM. PQM may work for companies or projects with a large developer group but not for Python. I fear it'd cause more problems than it's worth. There are valid reasons for checking in failing unit tests. For example a developer spots a problem but isn't able to fix on his own. Any fancy system that delays or prohibits check-ins is going to slow us down. In my opinion a system like PQM should only be used when a RC or final release is immanent. I can picture the usefulness of PQM during the last few weeks before a release. I'd rather see the man power put into better testing facilities than into a tool like PQM. If you are worried about the stability of the trunk I'd rather suggest a change of our code of conduct. For example every change of code, which isn't just a minor change, must be applied to a new branch and reviewed by a second developer before it's applied to the trunk. I think development inside branches and peer reviewing yield better results than a machine that rules over developers. Christian, who still thinks (hopes) that the human mind outperforms machines when it comes down to important and complex decisions. ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 7:33 PM, Martin v. Löwis wrote: Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. Why is that qualitatively different than a security fix? All the same conditions apply. No. The problem being fixed is completely different. For a security fix, it is typically fairly obvious what the bug being fixed is (in particular, if you look at the recent ones dealing with overflows): the interpreter crashes without the patch, and stops crashing (but raises an exception instead) with the patch. That's true of a certain class of bugs, probably mostly in the C code. I think potential security bugs in Python code will be closer to "regular" bug fixes. I'm glad it wasn't much effort. Would you propose using technological means to close the branch? They are still open for security patches (well, 2.4 is; under my proposed policy, 2.3 isn't anymore). If people think it's desirable, we could rename the branch, or we could enforce a certain keyword (e.g. "security") in the commit messages. I was thinking about preventing commits on the branch. Most security fixes of the type you describe come in through the psrt, and they may even be embargoed. For a closed branch, you'd open it for the security patches when the embargo is lifted, make the commits, then close it again. That would at least be a very strong clue that the branch is closed :). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKOxEHEjvBPtnXfVAQLnDwP/SxtyECt++5uvFKdwIkop7xP2tyLy7IBW sigKb7WOvVH/Iiz16xf7zdEuXqsV1h59QvPDCzwk8/6VTggjbfhZ9qt+PdwlClzL cbc1JFI0DSDQ8tVOiPtJhsvvAhXMAlZI5FmMRxp77Cc3y9JUwczxzIP2fXw4IvUQ K6WO3bLbY5s= =USCq -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 7:52 PM, Bill Janssen wrote: PQM serializes changesets so that they must apply cleanly with no conflicts, and pass the entire test suite. What platform would it run the test suite on? Presumably the same one I tested on before I submitted the patch :-). I think we'd just have to pick one. It would probably be a *nix based system. I think this works if you're a Linux development shop, but perhaps not as well for Python. It would still solve a problem we have today, which is that the release branch is very often broken when the time comes to cut a release. We've had to delay several releases because of red buildbots or failing tests across multiple platforms. Even having the branch always releasable on Linux would be a big improvement. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCUAwUBSKOxsXEjvBPtnXfVAQLjdgP3RbRUTJybYA2EiSLcP8elEgsZAnF1Ej+b pPmRxghXgszla/wDIhlBqP2kmwPefe9svpG7bknwvgCVdk6cf0KdkGlhrFqVUAsm iYle1QEB43R7AleuF84rW3ECYriww7wTUtRjTzxGP7SMX+atEUY/ryF5rwaue313 XrrEYtXitQ== =U4fN -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
On Wed, Aug 13, 2008 at 6:12 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Barry Warsaw wrote: >> >> PQM = Patch Queue Manager >> >> Basically, it's a robot that controls commits to the trunk. Nothing lands >> in the trunk without getting through PQM first. PQM serializes changesets >> so that they must apply cleanly with no conflicts, and pass the entire test >> suite. There could be other conditions, e.g. that it lints cleanly, has no >> whitespace issues, etc. > > Personally I'm totally against any kind of tool like PQM for general > development. Issues due erroneous check-ins are a social problem. I strongly > believe that social problems can't be solved by a system like PQM. PQM may > work for companies or projects with a large developer group but not for > Python. > I fear it'd cause more problems than it's worth. There are valid reasons for > checking in failing unit tests. For example a developer spots a problem but > isn't able to fix on his own. Any fancy system that delays or prohibits > check-ins is going to slow us down. > > In my opinion a system like PQM should only be used when a RC or final > release is immanent. I can picture the usefulness of PQM during the last few > weeks before a release. > > I'd rather see the man power put into better testing facilities than into a > tool like PQM. If you are worried about the stability of the trunk I'd > rather suggest a change of our code of conduct. For example every change of > code, which isn't just a minor change, must be applied to a new branch and > reviewed by a second developer before it's applied to the trunk. I think > development inside branches and peer reviewing yield better results than a > machine that rules over developers. > > Christian, who still thinks (hopes) that the human mind outperforms machines > when it comes down to important and complex decisions. [Hey Christian, welcome back! (It seems we hadn't heard much from you for a while...)] 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. I do think that better tools can help us some -- while you can't solve every social problem with tools, the reverse isn't true either -- sometimes it *is* possible to solve (or at least alleviate) social problems with tools. As long as we're touting tools or processes that we have experience with, Google uses a combination of tools. One tool is similar to the buildbots, running tests *after* stuff has been checked in. A feature that buildbot is missing is that it tries to figure which checkin is responsible for a particular failure, and mails both the author of that change and the owner of the code (if different). Another tool that helps code quality tremendously is mandatory peer reviews of all code before checkin. Call me biased because I wrote the first version of the tool that most Googlers today use for peer reviews (Collin Winter now runs that show) and also open-sourced a similar tool (Rietveld, http://codereview.appspot.com) that works with Subversion. But I didn't set the policy of mandatory pre-checkin peer reviews -- Google had that policy for years before, and other tools had already been written. I particularly like the peer review policy because it is actually largely a *social* solution: code review is a very social process, the tools are secondary. By peer-reviewing all code before it goes in, not only do you catch many problems in an earlier stage than otherwise possible, but it also ensures that there are always at least two developers who know and understand the changes (or new code -- everything gets reviewed, even doc changes and changes to build files). Plus, it improves relationships between developers: if yesterday I found a bug in your code during peer review, today I may be more susceptible to you pointing out bugs in *my* code. This is a lot better than finding bugs during debugging sessions: once you've spent an hour tracking down a nasty bug you're much more likely to have a low opinion of whoever checked in the buggy code, and you're less likely to trust their judgment of your own code. Anyway, if we're going to change policies around submitting code, I would much rather see peer review become a habit than adopt a tool like PQM. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 9:12 PM, Christian Heimes wrote: Barry Warsaw wrote: PQM = Patch Queue Manager Basically, it's a robot that controls commits to the trunk. Nothing lands in the trunk without getting through PQM first. PQM serializes changesets so that they must apply cleanly with no conflicts, and pass the entire test suite. There could be other conditions, e.g. that it lints cleanly, has no whitespace issues, etc. Personally I'm totally against any kind of tool like PQM for general development. Issues due erroneous check-ins are a social problem. I strongly believe that social problems can't be solved by a system like PQM. Unfortunately, they're not being solved without PQM either! Really, we've had to delay releases several times because the branches were broken across multiple operating systems. Pleading on the mailing lists doesn't help. Hanging out on irc doesn't help. Having Benjamin, Georg, and others kicking ass on #python-dev the day of a release, is great, but it's also asking a lot of them. PQM may work for companies or projects with a large developer group but not for Python. I fear it'd cause more problems than it's worth. There are valid reasons for checking in failing unit tests. For example a developer spots a problem but isn't able to fix on his own. Any fancy system that delays or prohibits check-ins is going to slow us down. That's what branches are for. I really strongly feel that the mainlines (by which I mean the branches we cut releases from) should always be in a releasable state. We should never be committing broken tests to these mainlines. If you spot a problem you can't fix, create a branch and commit the broken test there, and ask for help with that branch. The mainline isn't (IMHO) the place for that. You're right that it will slow us down, but only on the mainline. That's a good thing, especially if it buys you high quality. In my opinion a system like PQM should only be used when a RC or final release is immanent. I can picture the usefulness of PQM during the last few weeks before a release. We should be using the same quality assurance early in the cycle that we do late in the cycle. Realistically, we're never going to switch to something different when we get to RC. I'd rather see the man power put into better testing facilities than into a tool like PQM. If you are worried about the stability of the trunk I'd rather suggest a change of our code of conduct. For example every change of code, which isn't just a minor change, must be applied to a new branch and reviewed by a second developer before it's applied to the trunk. I think development inside branches and peer reviewing yield better results than a machine that rules over developers. These are good policies to adopt. I know of many projects that require one or two positive code reviews for branches to land in the mainline. Code reviews and PQM augment each other though, they don't replace each other. We're all human and code reviews will never be perfect. Some changes have non-local or unexpected effects that only the test suite will catch. Maybe the test pass on your machine because of something in your environment that breaks in the PQM "ideal" environment. Christian, who still thinks (hopes) that the human mind outperforms machines when it comes down to important and complex decisions. It's not us vs. them. I want the machines to do the crappy grunt work so us humans can do what we do best, being creative and having fun :). Begging people to fix broken buildbots on release day is neither. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKO2EnEjvBPtnXfVAQIkzwP/cRwyLdkl27NoB3RYoWHzjv17EqeB+1Ha sjlZ9cuYtIZG3j7YHd11BoUcpbS5ZIUHq1J9PTVdUGrqNRAdCYIZuppM2XSE95ir lNj2VSZ0th6g0NeIcPpMTzdNOxp+OJ/np0U+k7zKJOoJl1+HopGJg3+LsO6h/XRs Ysg1yN9BMAY= =D6Zz -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 10:49 PM, Brett Cannon wrote: If any of the set of conditions fail, the changeset does not land. This means that the trunk is always in a releasable state, and we avoid the problems I run into all the time now, where we have red buildbots on or near release date. I would dearly love to be able to spin a release at any time and have a high degree of confidence that what I'm releasing is stable. Well, it would definitely catch those changes that manage to break ALL the buildbots, but those that only break on the platforms that the developer is not on might just cause pain. That's a downside of PQM, but still, someone's gotta fix the pain. Ideally, it would be the developer who committed the broken change. The problem of not having access to all the platforms, or not being able to debug problems on those platforms is a different issue. There's a specific implementation of PQM based on the Bazaar revision control system, available here: https://edge.launchpad.net/pqm Why am I not surprised that bzr has support for something you are suggesting? =) Hey, a good tool is a good tool. :) But really, I think the process is the important thing, then find the tools that make that process easy. PQM is not perfect, nor is it a perfect fit for us. For example, we have buildbots that run on multiple platforms, while PQM runs on a single platform. So a vanilla PQM could still miss changes that break only on a specific operating system. It also doesn't help at all for bugs not covered by the test suite (well, buildbots don't help there either ;). PQM also introduces delays on trunk landing because it serializes commits. So when things get backed up, it might take a while for your branch to land on the trunk. There is also the shift in development style to larger patch sets (assuming your version control system supports patch sets) instead of a lot of incremental commits to the trunk since you might end up with a cascading failure of your commits if you were dependent on an earlier one fails and thus all your subsequent checkins will be rejected. Yep. Figure out what you want, then find the tools that fit. :) PQM wouldn't replace the buildbots, but it would greatly improve the quality of the development branches, IMO. The buildbots would still be useful to ensure cross-platform quality. Well, another option is to flesh out ``make check`` such that it runs more sanity checks and makes sure the entire test suite is run and passed before a commit is done, basically doing what you are suggesting, but on a local level. Hook that into svn commit so that you /have/ to run it, and maybe you can convince me. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKO3nnEjvBPtnXfVAQKMbQP/XSVQ5ACG9JXrl30Jfodg2anrIPYcWjyb +JCqs0Bbgy6vqeI3h0g5AlsKQbUBRbCXq2tqUVNgWjgWCUoofuU4Uw/2YieJa3Tc KcIsHeI8YcpnGW5e0ipXEPG/9B9m3T4UVybk8N3LQ7SW8ca6oRZgH7EgKEgmwHD0 SCIMtVDXgQk= =7ojY -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 14, 2008, at 12:16 AM, Guido van Rossum wrote: 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. Just quickly because I've touched on most of these issues in previous responses, and I'm pretty damn tired right now. ;) - - Code reviews: +1 I agree with everything you said here Guido. - - Buildbots: good for what they do, but because they're reactive (and in our case, quite often not working) they don't solve a problem, they're an indicator of the problem - - 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. - - All three can work together to solve different parts of the problem. None (IMHO) are enough on their own. I'm skeptical that reviews + buildbots are enough. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKO5n3EjvBPtnXfVAQL8OgP9FvF8k6NACevHnfwbnOc9YsMe8ScyZ3sG 9HOwLn70G7TXT0Lg3izT+VnLXhAbMUm7a0fNJXStTrWmfMvIiHLqs8W1wdKoJSTN kyTgpx0p8LkryBfakq09D/nknlylajGfr21vT5zXS5+irgURIq1FW/u7Ry9pzT5l QtSZ8EyWR2Y= =c342 -END PGP SIGNATURE- ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] [Python-Dev] next beta
> That's true of a certain class of bugs, probably mostly in the C code. > I think potential security bugs in Python code will be closer to > "regular" bug fixes. While that may be true, I think that are much more infrequent, because many attack paths (such as memory overwrites leading to remote code execution) just don't exist. In many cases, it's clear that it is the application that uses the library in an insecure manner, so many security fixes involving Python code will be in the applications, not the library. In fact, I only recall a single security-related bug fix of Python code, advisory PSF-2005-001: XML-RPC would allow to invoke arbitrary Python code. In fixing this, valid uses might have been broken, so the patch added the allow_dotted_names attribute for such applications. Clearly, quite some time went into designing a fix for this problem, much more than for a regular bug fix. This is comparatively ok, since security fixes for Python library code are so rare. > I was thinking about preventing commits on the branch. Most security > fixes of the type you describe come in through the psrt, and they may > even be embargoed. For a closed branch, you'd open it for the security > patches when the embargo is lifted, make the commits, then close it > again. That would at least be a very strong clue that the branch is > closed :). That would be fairly easy to do. If there is consensus what branches are closed, I can come up with a pre-commit hook. Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
Re: [python-committers] PQM?
> As long as we're touting tools or processes that we have experience > with, Google uses a combination of tools. One tool is similar to the > buildbots, running tests *after* stuff has been checked in. A feature > that buildbot is missing is that it tries to figure which checkin is > responsible for a particular failure, and mails both the author of > that change and the owner of the code (if different). Buildbot does have a blame list. Mailing the developer failed so far because we didn't have email addresses of each developer. Now, with the python-committers list, Brett collected them, so such mailing would be possible. I'm not sure about mailing the owner of the code: we don't typically have owners of code, right? Would you consider it useful to support the case were we do have an owner? Such an ownership database would need to be maintained, as well, and typically, when we do have owners, the owner is also the committer. > Another tool that helps code quality tremendously is mandatory peer > reviews of all code before checkin. Call me biased because I wrote the > first version of the tool that most Googlers today use for peer > reviews (Collin Winter now runs that show) and also open-sourced a > similar tool (Rietveld, http://codereview.appspot.com) that works with > Subversion. But I didn't set the policy of mandatory pre-checkin peer > reviews -- Google had that policy for years before, and other tools > had already been written. So would you enforce that policy with tools, too? If so, what would the workflow look like? > Anyway, if we're going to change policies around submitting code, I > would much rather see peer review become a habit than adopt a tool > like PQM. The part where I'm skeptical about such a policy is that there might be a shortage of reviewers. What if a patch on Rietvield doesn't find a reviewer for a month or so? Many patches in the tracker sit there for years without any committer reviewing them. Regards, Martin ___ python-committers mailing list [email protected] http://mail.python.org/mailman/listinfo/python-committers
