[Python-Dev] memory leaks in 2.2

[David Ascher]

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 <wink>.

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