Here is a list of all the outstanding memory leaks from the regression tests. All of these leaks have a bug report on SF. test_descr: 117 bytes (0.0407%) test_email: 30 bytes (0.0149%) test_re: 30 bytes (0.0149%) test_richcmp: 16 bytes (0.0106%) test_scope: 39 bytes (0.031%) test_sre: 188 bytes (0.137%) test_symtable: 12 bytes (0.00991%) test_unicode: 66 bytes (0.0224%) syntax error in interpreter: 38 bytes (0.05%)
[Neal Norwitz]
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. have-some-fun-plug-a-leak-ly y'rs - tim
[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>.
Tim Peters writes:
Aside from these specific memory-leak reports, we've generally fallen down on bug triage. 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 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. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
[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.
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
:-) 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 :-) 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. Regards, Martin
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]
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. If you can get the open bugs to fit on one screen, it tends to stay that way; once it spills over a screen, it appears there's no bound on how many additional screens are tolerated (0, 1, infinity). I'm doing my part by reducing my font size and buying a much larger monitor <wink>.
[Tim]
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/)
[Tim]
[Guido]
It depends on what the bugs are.
Actually, it would not have: a backlog of that many bugs (regardless of nature) would mean they'd never get fixed -- it's hopeless. Time then to cut losses. The compilers I worked on previously sold multi-million dollar machines, though, and had to work only with our own OS(es) and libraries. Python's life is more complicated than that -- and Python doesn't have a few hundred open bugs anyway (there are only 183 right now <wink>). The Python bug base also has gripes about everything from docs to python-mode.el in it.
Those should be closed after a reasonable time: nobody is going to work on them. OTOH, I don't think there are many *open* bugs of this ilk (I routinely close such after a month, with "closed for lack of requested followup" -- and nobody has complained about that).
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.
I don't think there are many open bugs of that ilk either.
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 did my part against bugs without someone to ask for more info by forbidding anonymous bugs, recently.
Appreciated, but those were the easiest to close <0.9 wink>. the-things-that-get-done-are-the-things-that-get-worked-on-ly y'rs - tim
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 wrote:
...rewrite it from scratch.
more likely, buy one from EDG: http://www.edg.com/customers.html </F>
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
"FLD" == Fred L Drake, <fdrake@acm.org> writes:
FLD> Martin v. Loewis writes:
I think the only time we were close was when the database was new.
FLD> No; when the DB was new (but old enough to notice), it FLD> contained an FLD> import of all the old JiterBug reports. I think we had it FLD> pretty well whittled down around the 2.0 release. That's right. We spent a lot of time fixing bugs prior to the 2.0 release. Jeremy
[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]
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.
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>.
tim wrote:
If any language I worked on previously had a few hundred open bug reports (not counting feature requests).
btw, what's the right way to flag something as a feature request? both the data type and the group fields can be set to "feature request", but I'm not allowed to change the former. (and all my feature requests are listed under "Python - Bugs") </F>
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
[Fredrik Lundh]
After literally hundreds of mouse clicks, just about everyone should have permission to do that now. The "data type" field determines the tracker a thing lives in, so that's the more important of the two to change. Unfortunately, when you move a report, old URLs to the report become invalid, and bring up a bizarre "invalide artifact ID" (something like that) page.
(and all my feature requests are listed under "Python - Bugs")
Then I'm going to raise them all to priority 9 <wink>.
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).
Tim Peters wrote:
Would be nice if we could also have Groups "Python 2.3", "Python 3k", etc.
Changing the data type pretty much reset all fields for me (including the assigned field which is particularly annoying) and the URL becomes invalid too. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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
"Martin v. Loewis" wrote:
If you look at it this way, yes. It's just that setting the Group to e.g. P3k would tell the submitter that the request is being considered, but won't get implemented until a few releases from now or that a specific request won't make it into e.g. Python 2.2 because of a feature freeze. Anyway, it's just an idea. BTW, I also think that we could use the feature request tracker to track all the PEP 42 requests and redirect PEP 42 to the tracker. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
Tim Peters wrote:
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
To report on the processes of another project; GCC organizes people in "blanket write priviledge", "maintainers" (CPU port, OS, misc), and "write after approval". The blanket priviledge allows people to commit contributions they have reviewed from contributors without any write access; those are used sparingly. Maintainers can change "their" files any time they like, except after a freeze. Everybody else must wait for a patch review. Regards, Martin
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
"Fred L. Drake, Jr." wrote:
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. [BTW -- I know this isn't the right channel, but we (the Komodo team) have found a couple of bugs in popen recently which y'all may not have seen yet and you might want to tackle for 2.2 -- we'll get them in SF in the next few days hopefully, but this is better than nothing: - popen on Windows XP seems problematic (needs a repro test there -- not analyzed yet) - 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 =)]
One thing the Mozilla community has going for it is really dedicated QA folks. One in particular, Asa Dotzler, does an amazing job at bug triage, categorization, etc. He's now a Netscape employee, but used to do this for fun. It would be a good way for someone who'se 'on the periphery' to get more deeply involved and learn a lot. In general, that kind of QA job can be a gateway to fame and fortune much like documentation writing can be, and you really get to learn the product/technology. I don't have first-hand experience of the success of bug days, but they're doing more of them, so they must get some value out of them. --david guessing-from-the-"it hurts! then don't do that!"-corrolary ascher
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
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/)
Never mind, with Ping's hint I see a leak. I'll fixit momentarily. --Guido van Rossum (home page: http://www.python.org/~guido/)
I'll take test_descr.py right now. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 5 Dec 2001, Neal Norwitz wrote:
Okay, i have tested this case and narrowed it down to: while 1: class C: __metaclass__ = type Try it on a Python interpreter near you. With mine, it grows without bound. As far as i can tell, of all the calls in test_descr.test_main, only metaclass() leaks memory. -- ?!ng
"NN" == Neal Norwitz <neal@metaslash.com> writes:
NN> Here is a list of all the outstanding memory leaks from the NN> regression tests. All of these leaks have a bug report on SF. I don't see an SF bug report for test_scope. If you have any data from Purify, that would be helpful. It certainly looks like it's leaking. Jeremy
[Neal Norwitz]
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. have-some-fun-plug-a-leak-ly y'rs - tim
[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>.
Tim Peters writes:
Aside from these specific memory-leak reports, we've generally fallen down on bug triage. 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 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. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
[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.
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
:-) 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 :-) 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. Regards, Martin
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]
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. If you can get the open bugs to fit on one screen, it tends to stay that way; once it spills over a screen, it appears there's no bound on how many additional screens are tolerated (0, 1, infinity). I'm doing my part by reducing my font size and buying a much larger monitor <wink>.
[Tim]
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/)
[Tim]
[Guido]
It depends on what the bugs are.
Actually, it would not have: a backlog of that many bugs (regardless of nature) would mean they'd never get fixed -- it's hopeless. Time then to cut losses. The compilers I worked on previously sold multi-million dollar machines, though, and had to work only with our own OS(es) and libraries. Python's life is more complicated than that -- and Python doesn't have a few hundred open bugs anyway (there are only 183 right now <wink>). The Python bug base also has gripes about everything from docs to python-mode.el in it.
Those should be closed after a reasonable time: nobody is going to work on them. OTOH, I don't think there are many *open* bugs of this ilk (I routinely close such after a month, with "closed for lack of requested followup" -- and nobody has complained about that).
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.
I don't think there are many open bugs of that ilk either.
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 did my part against bugs without someone to ask for more info by forbidding anonymous bugs, recently.
Appreciated, but those were the easiest to close <0.9 wink>. the-things-that-get-done-are-the-things-that-get-worked-on-ly y'rs - tim
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 wrote:
...rewrite it from scratch.
more likely, buy one from EDG: http://www.edg.com/customers.html </F>
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
"FLD" == Fred L Drake, <fdrake@acm.org> writes:
FLD> Martin v. Loewis writes:
I think the only time we were close was when the database was new.
FLD> No; when the DB was new (but old enough to notice), it FLD> contained an FLD> import of all the old JiterBug reports. I think we had it FLD> pretty well whittled down around the 2.0 release. That's right. We spent a lot of time fixing bugs prior to the 2.0 release. Jeremy
[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]
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.
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>.
tim wrote:
If any language I worked on previously had a few hundred open bug reports (not counting feature requests).
btw, what's the right way to flag something as a feature request? both the data type and the group fields can be set to "feature request", but I'm not allowed to change the former. (and all my feature requests are listed under "Python - Bugs") </F>
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
[Fredrik Lundh]
After literally hundreds of mouse clicks, just about everyone should have permission to do that now. The "data type" field determines the tracker a thing lives in, so that's the more important of the two to change. Unfortunately, when you move a report, old URLs to the report become invalid, and bring up a bizarre "invalide artifact ID" (something like that) page.
(and all my feature requests are listed under "Python - Bugs")
Then I'm going to raise them all to priority 9 <wink>.
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).
Tim Peters wrote:
Would be nice if we could also have Groups "Python 2.3", "Python 3k", etc.
Changing the data type pretty much reset all fields for me (including the assigned field which is particularly annoying) and the URL becomes invalid too. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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
"Martin v. Loewis" wrote:
If you look at it this way, yes. It's just that setting the Group to e.g. P3k would tell the submitter that the request is being considered, but won't get implemented until a few releases from now or that a specific request won't make it into e.g. Python 2.2 because of a feature freeze. Anyway, it's just an idea. BTW, I also think that we could use the feature request tracker to track all the PEP 42 requests and redirect PEP 42 to the tracker. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
Tim Peters wrote:
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
To report on the processes of another project; GCC organizes people in "blanket write priviledge", "maintainers" (CPU port, OS, misc), and "write after approval". The blanket priviledge allows people to commit contributions they have reviewed from contributors without any write access; those are used sparingly. Maintainers can change "their" files any time they like, except after a freeze. Everybody else must wait for a patch review. Regards, Martin
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
"Fred L. Drake, Jr." wrote:
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. [BTW -- I know this isn't the right channel, but we (the Komodo team) have found a couple of bugs in popen recently which y'all may not have seen yet and you might want to tackle for 2.2 -- we'll get them in SF in the next few days hopefully, but this is better than nothing: - popen on Windows XP seems problematic (needs a repro test there -- not analyzed yet) - 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 =)]
One thing the Mozilla community has going for it is really dedicated QA folks. One in particular, Asa Dotzler, does an amazing job at bug triage, categorization, etc. He's now a Netscape employee, but used to do this for fun. It would be a good way for someone who'se 'on the periphery' to get more deeply involved and learn a lot. In general, that kind of QA job can be a gateway to fame and fortune much like documentation writing can be, and you really get to learn the product/technology. I don't have first-hand experience of the success of bug days, but they're doing more of them, so they must get some value out of them. --david guessing-from-the-"it hurts! then don't do that!"-corrolary ascher
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
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/)
Never mind, with Ping's hint I see a leak. I'll fixit momentarily. --Guido van Rossum (home page: http://www.python.org/~guido/)
I'll take test_descr.py right now. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 5 Dec 2001, Neal Norwitz wrote:
Okay, i have tested this case and narrowed it down to: while 1: class C: __metaclass__ = type Try it on a Python interpreter near you. With mine, it grows without bound. As far as i can tell, of all the calls in test_descr.test_main, only metaclass() leaks memory. -- ?!ng
"NN" == Neal Norwitz <neal@metaslash.com> writes:
NN> Here is a list of all the outstanding memory leaks from the NN> regression tests. All of these leaks have a bug report on SF. I don't see an SF bug report for test_scope. If you have any data from Purify, that would be helpful. It certainly looks like it's leaking. Jeremy
participants (10)
-
David Ascher -
Fred L. Drake, Jr. -
Fredrik Lundh -
Guido van Rossum -
Jeremy Hylton -
Ka-Ping Yee -
M.-A. Lemburg -
Martin v. Loewis -
Neal Norwitz -
Tim Peters