[Tim]

more may be lurking. It's not a Good Sign that test_binop has vanished from the list now but everything else is still there.

[Fred L. Drake, Jr.]

Err, test_parser is no longer on the list!

Which is bad news: it means that test_binop and test_parser had leaks for reasons independent of each other, and of all the others on the list: we're not making swift progress on these. You only looked at test_parser because Guido assigned it to you. I only looked at test_binop because I was coughing too hard to get any difficult work done <wink>.

[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'm not sure what we can do about this in the short term, but I really think we're not doing as good a job at this as we should be.

I think it's just one of many areas where we "should be" doing a better job.

I wonder if we could take a lesson from the Mozilla community and organize Bug Days (group hack days where the goal is to resolve bugs) or have a "BugAThon" where we call for smaller/simpler test cases that exercise reported bugs. I suspect a page about how to narrow down a bug to a smaller test case would be very helpful, especially if it also discusses how to use the various available tools for things like pinpointing leaks, etc.

Frankly, I don't think it will help. If you look at the bug statistics, we've made steady and dramatic improvement in bug turnaround time over the last six months, and we can't sustain even that improvement. Fact is we have very few people fixing bugs or reviewing patches. It's not like the majority of Python developers work on this stuff in spurts, it's that most don't work on it at all, and almost nobody works on it routinely. We couldn't even meet our modest internal (admittedly imposed by me <wink>) "close one bug or patch per day per person" goal last week (you'll never see that idea again either ...). Maybe we should resume offering a free copy of the next Python release to contributors working beyond the bounds of sanity? Na -- even Thomas eventually figured out he could get a free copy anyway -- let's just pray he doesn't tell Martin <wink>. better-at-eating-kung-pao-chicken-than-motivating-the-overburdened- to-spread-themselves-thinner-than-gas-ly y'rs - tim

As for the things we should change: I believe it is pointless to sit on a report for a long time without doing anything about this. If nothing happens for a year, the person that was assigned this report likely won't do anything about it for the next months, either. Unassigning things you know you won't do is particularly important for patches, but to a degree also important for bug reports. It signals that somebody else may need to step forward, or that some deity should just decide on the fate of this report.

Yup. We've missed important bugs in the past because they happened to be assigned to someone who didn't care. (I noticed that Jack recommended some bug reporter to assign bugs to him rather than let them sit anonymously. That may work in his case, but in general it's the wrong thing to do.) --Guido van Rossum (home page: http://www.python.org/~guido/)

[Martin v. Loewis]

...

:-) I personally don't see it as a problem that bug reports are piling up. The GCC GNATS has 1341 "open" bug reports (meaning either "open" or "analyzed") at the moment. bugzilla.mozilla.org reports 19611 bugs in the "open" categories. Microsoft reportedly has over 60000 open reports for Windows 2000. Neither of these groups despair :-)

[Tim]

If any language I worked on previously had a few hundred open bug reports (not counting feature requests), we would have shut the group down and pursued a new implementation.

It depends on what the bugs are. Many bugs in our tracker are intractable because we don't have the platform where it occurs or the user didn't supply enough information to reproduce it. I imagine the GCC bugs are much of the same, just more (because GCC is more complex and wider used than Python -- most GCC users are even more clueless about GCC's implementation than Python users are about Python's implementation). I try to close bugs from clueless users if there's no response to a request for more info, but often something that might be a bug but isn't easily reproduced stays open for many many months. So I'm not sure that it's realistic to keep all bugs on a page. I did my part against bugs without someone to ask for more info by forbidding anonymous bugs, recently. --Guido van Rossum (home page: http://www.python.org/~guido/)

My only interaction with the gcc bug base was helping to whittle down oodles of bad codegen cases on new ports. I have no idea what else may be in there.

Many of them are of this kind. As a C++ person, I notice also (with regrets) that a significant portion is of the kind "C++ compiler rejects valid code, or crashes". They are easy to reproduce, so they probably would have caused your former companies to throw away the C++ front-end and rewrite it from scratch. In g++, this won't happen: nobody has the resources to rewrite it from scratch. And even with these bugs, g++ still is much better than the competition :-)

...

So I'm not sure that it's realistic to keep all bugs on a page.

We were close once. Now the open patches don't even fit on a page.

I think the only time we were close was when the database was new. Regards, Martin

Martin v. Loewis writes:

I think the only time we were close was when the database was new.

No; when the DB was new (but old enough to notice), it contained an import of all the old JiterBug reports. I think we had it pretty well whittled down around the 2.0 release. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

[Tim]

...

My only interaction with the gcc bug base was helping to whittle down oodles of bad codegen cases on new ports. ...

[Martin v. Loewis]

Many of them are of this kind. As a C++ person, I notice also (with regrets) that a significant portion is of the kind "C++ compiler rejects valid code, or crashes". They are easy to reproduce, so they probably would have caused your former companies to throw away the C++ front-end and rewrite it from scratch.

As Fredrik suggested, we bought front ends whenever possible. When a single machine sells for millions, and you can buy a highly regarded front end for a few percent of that, you'd be crazy to write your own.

In g++, this won't happen: nobody has the resources to rewrite it from scratch. And even with these bugs, g++ still is much better than the competition :-)

I'd be more upset if anyone had proved that C++ is compilable <wink>. [Guido]

...

...

So I'm not sure that it's realistic to keep all bugs on a page.

...

We were close once. Now the open patches don't even fit on a page.

I think the only time we were close was when the database was new.

As Fred and Jeremy said, when we (PythonLabs) worked intensely on closing bugs for 1.6 and 2.0, we were close to being in phenomenal shape here. We don't have a fraction of the internal resource to throw at that anymore, though, and volunteers haven't taken up the slack. So I figure the only reason Python stays in exceptionally good bug shape is that we also ignore the contributed patches <0.9 wink>.

btw, what's the right way to flag something as a feature request?

I'd prefer to see them in the Feature Requests tracker. The Feature Requests group predates the separate feature requests tracker; if they are in a separate tracker, people won't have to go over them again and again

both the data type and the group fields can be set to "feature request", but I'm not allowed to change the former.

At the moment, it might be fastest if you post the numbers, so I can reclassify them. Alternatively, someone with appropriate powers could give you write access to the feature requests tracker, and the data type field (I think you need to be tracker admin for that). Regards, Martin

The SF Feature Request tracker didn't have any Categories defined. I've now added the same Categories as are available in the Bug tracker: Build Demos and Tools Distutils Documentation Extension Modules IDLE Installation Macintosh Parser/Compiler Python Interpreter Core Python Library Regular Expressions Threads Tkinter Type/class unification Unicode Windows XML Caution: it *could* be that when you change trackers, the Category is lost; you may have to set it again after it's moved (this was certainly the case when the FR tracker didn't have any Categories).

Would be nice if we could also have Groups "Python 2.3", "Python 3k", etc.

I'm not sure. Feature requests are supposed to stay open until they are either implemented, withdrawn, or rejected for good. If you want to express that some requests are more important than others (so that they ought to go into 2.3, instead of P3k), you should give them a higher priority. Regards, Martin

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

Tim Peters writes:

better-at-eating-kung-pao-chicken-than-motivating-the-overburdened- to-spread-themselves-thinner-than-gas-ly y'rs - tim

Ah, but gas can be spread infinately thin -- something that can't be said of most developers! ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

It's hard. Bugzilla has some good features there w.r.t. "unverified" vs. "new" vs. "accepted" and "fixed" vs "resolved", QA contacts, keyword handling for milestone/release targets, etc. I'm not sure how the SF bugtracker compares in practice but from a distance it seems a little weak there.

SF recommends to use the Group for "unsupported", "unverified". Unfortunately, the filtering capabilities leave a lot of wishes.

- popen on Posix has a nasty failure mode if the cmd argument is Unicode (see the first line in Popen3._run_child for a hint =)]

You mean, def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] :-? Fixed since 2001/12/02.

It would be a good way for someone who'se 'on the periphery' to get more deeply involved and learn a lot.

This is free software. Most contributors work on it for fun, or because they need it for their job. Posting "volunteers needed" may be a good idea, but then, perhaps not so shortly before 2.2. Regards, Martin

...

...

It would be a good way for someone who'se 'on the periphery' to get more deeply involved and learn a lot.

This is free software. Most contributors work on it for fun, or because they need it for their job.

Sure. Are you disagreeing with something I said?

No. I just think this won't help much. Just because it would be good for somebody doesn't mean that this somebody will actually invest time into the project. People normally get involved by other means than starting as a bug/patch reviewer. Typically, they get involved because they need something fixed that apparently nobody else has fixed for them while they were waiting for it (atleast that's how I got involved in all free software projects I was working on). Regards, Martin

I can't find a leak in test_descr.py when I simply call test_main() in an infinite loop. (I can when I use reload() in the loop, but that's an import issue I believe.) Neil, did you test this before or after I fixed the __slots__ leak? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

...

I can't find a leak in test_descr.py when I simply call test_main() in an infinite loop. (I can when I use reload() in the loop, but that's an import issue I believe.)

Neil, did you test this before or after I fixed the __slots__ leak?

Never mind, with Ping's hint I see a leak. I'll fixit momentarily.

In test_descr, buffer_inherit() leaks 35 bytes which may indicate the problem. Neal

Can anyone lend a hand here? Take a test, stick it in an infinite loop, watch your process size blow off the roof, then whittle the test down until the trigger becomes clear. We found a very serious 2.2 leak today doing this to test_binop.py, and not even Guido (let alone God ...) knows how many more may be lurking. It's not a Good Sign that test_binop has vanished from the list now but everything else is still there.

I'll take test_descr.py right now. --Guido van Rossum (home page: http://www.python.org/~guido/)