A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-March/020744.html below:

[Python-Dev] Moving bugs and patches through the pipeline more quickly

[Python-Dev] Moving bugs and patches through the pipeline more quicklyMichael Hudson mwh@python.net
08 Mar 2002 10:04:34 +0000
Tim Peters <tim.one@comcast.net> writes:

> [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



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4