[Python-Dev] memory leaks in 2.2 (original) (raw)

David Ascher DavidA@ActiveState.com
Wed, 05 Dec 2001 23:39:08 -0800

Tim Peters wrote:

[Fred L. Drake, Jr.] > Aside from these specific memory-leak reports, we've generally > fallen down on bug triage. Look on the bright side: we're doing a much better job on bugs than on patch review, and our patch review work in turn is stellar compared to what we've accomplished in the PSF .

I'll pipe in with our experience with Mozilla & Komodo, which have related but different processes.

Mozilla has a very strict review process. Up to two reviews and one super-review for each checkin (http://www.mozilla.org/hacking/reviewers.html). 99% of all communication is done through comments & patches attached to bugs. It works for them, in that the quality of the code checkins tends to be high, but it's a fairly imposing process (which is limiting the number of contributors, I expect -- not because the process is that hard to follow, but it's hard to discover and learn and adopt, especially as part of a side project).

In the Komodo team, the number and type of reviews we require depends on the stage of the product (how close we are to release). We used to have periods when no review was needed, but I think we're going to keep the minimal one-review requirement on indefinitely. At critical times we've even had a "change review board" process in place. Having tools that generate good patches with 'proposed changelogs' and apply them safely, good integration between the source code control system and the bug tracking system are all good things which have made our code quality go up as well. Bugzilla is a good patch manager as well.

It takes time to learn/teach how to be a good reviewer -- it's not the same kind of skill as writing a patch or logging a good bug. Review processes also affect 'superficial development speed' -- the patch author has to sit on a patch until the process is complete, and that can be frustrating. Also, to the extent that patches uncover other bugs, it can slow down the bug discovery process. Of course we wouldn't do it if we didn't feel it increased the long-term effective rate of quality increase.

Note that in both of the above cases, everyone must go through the review process, including the top dogs, for any change to the code base, build system, etc. (the documentation and test suite subtree are excluded usually). Note also that I don't mean to imply that the above process is the right one for Python. I'm just speaking on the processes I know something about =).

--david