Re: [Python-Dev] Moving bugs and patches through the pipeline more quickly
Tim Peters
[Jeremy Hylton]
When we were working on Python 2.0, PythonLabs made a serious commitment to keep the list of bugs on one page. Lots of people fixed bugs to achieve that goal, and more processing power will definitely help.
Note that we had full-time jobs working on Python then too. Well, not entirely: at the end of the BeOpen run, all of PythonLabs was unemployed, so we got to spend 1200% of every day volunteering to finish 2.0.
I think there are more bugs being submitted now, too. We should never have told anyone about that tracker <wink>.
One other thing that helped was that I spent many hours each week tracking bugs and making sure someone was working on them. I intend to pick that task up again for Python 2.3. It would be great if there were more developers to lean on for the bugs.
During the times I did that task, I spent about 30 hours per week on bug + patch triage alone.
It would be hard to overestimate how much concerted effort it would take to get back to "one page" again; the SF stats (I think only admins can view the reports)
Nope. At least, I can see them.
show that we're falling further behind month by month. The "Feature Requests" tracker may as well be a trash can.
It's probably better that PEP 42. That should probably be sliced up and moved back into the tracker.
OTOH, we could make a lot of progress very quickly by agreeing to drop Python support for all save the OS + compiler Guido happens to use <wink>.
Certainly. Life would be easier if we didn't have to worry about bugs like: [ 459464 ] Math_test overflowerror on sparc64 linux (to pick a random example). I don't think keeping open bugs <50 is a realistic goal unless there's at least one person working full time on keeping things that way, and that doesn't seem likely. OTOH, a certain amount of progress is being made as the result of the current guilt trip -- let's see how long that lasts <wink>. Cheers, M. -- This is an off-the-top-of-the-head-and-not-quite-sober suggestion, so is probably technically laughable. I'll see how embarassed I feel tomorrow morning. -- Patrick Gosling, ucam.comp.misc
I wrote a little script last night that scrapes all the open bugs from SF, compares them with those in a local MySQL database and reports on those that have been opened or closed since the last time the script was run. Output looks like New Bugs -------- httplib: multiple Set-Cookie headers http://python.net/crew/mwh/py/bug/432621 __cdecl / __stdcall unspecified in *.h http://python.net/crew/mwh/py/bug/471432 xml.AttributesImpl: __setitem__ undef. http://python.net/crew/mwh/py/bug/495672 telnetlib in debug mode http://python.net/crew/mwh/py/bug/508100 unicode() docs don't mention LookupError http://python.net/crew/mwh/py/bug/513666 The Closed Bugs section is formatted in a similar fashion but nothing's been closed since I ran it for the last time last night. Note that I'm using Michael's bug redirector because its URLs are shorter. I plan to also add the same capability for patches. I realize this probably overlaps badly with Jeremy's scraper, but are there people who are interested in seeing summaries like this? If so, are there enough people interested in this that I should send it to an existing list like python-checkins, or should I create a separate list? Skip
I plan to also add the same capability for patches. I realize this probably overlaps badly with Jeremy's scraper, but are there people who are interested in seeing summaries like this? If so, are there enough people interested in this that I should send it to an existing list like python-checkins, or should I create a separate list?
Great, Skip! If you do this once a week, posting to python-dev would be appropriate. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> If you do this once a week, posting to python-dev would be Guido> appropriate. Done. Sunday morning, 7AM, it compares the local info with the displayed into and send a summary mail to python-dev. The first run this Sunday will be thin because the database was last updated just a few minutes ago. Note that bugs or patches that are opened and closed quickly won't be seen, since all I'm doing is scraping the bug/patch browser. I don't think that's a big deal though. Easy fixes aren't what people need to be alerted to. Skip
Skip Montanaro
Done. Sunday morning, 7AM, it compares the local info with the displayed into and send a summary mail to python-dev. The first run this Sunday will be thin because the database was last updated just a few minutes ago. Note that bugs or patches that are opened and closed quickly won't be seen, since all I'm doing is scraping the bug/patch browser. I don't think that's a big deal though. Easy fixes aren't what people need to be alerted to.
If feasible, you might extract what SF gives as the total number of bugs/patches, and reporting the number of bugs that you did not account for. Regards, Martin
[Skip Montanaro]
... I plan to also add the same capability for patches. I realize this probably overlaps badly with Jeremy's scraper,
I doubt Jeremy bothers to run that anymore.
but are there people who are interested in seeing summaries like this?
Not me, but I'm very keen to force other people to see it <wink>.
If so, are there enough people interested in this that I should send it to an existing list like python-checkins, or should I create a separate list?
I agree with python-dev: if anyone on python-dev thinks bugs and patches are an irrelevant bother, they should unsubscribe. damn-i-love-getting-too-old-to-care<wink>-ly y'rs - tim
participants (5)
-
Guido van Rossum -
martin＠v.loewis.de -
Michael Hudson -
Skip Montanaro -
Tim Peters