Re: [Python-Dev] New bugtracker project

Guido van Rossum <guido@python.org> writes:
I believe that one of the areas where we could use help is a bug tracker.
If I may so bold, I suggest the distutils could use some (paid) tender loving care, too... [...]
The point of this message is to start gathering requirements. Gordon will gather requirements, and has asked me to send out this email to announce the project to the Python developer community.
1) An email interface (OK, so this has been said, and already exists, but...) 2) Not having this lunatic distinction between patches and bugs or restrictions on who can add files to issues, and let people delete at least their own attachments. Cheers, M. -- SPIDER: 'Scuse me. [scuttles off] ZAPHOD: One huge spider. FORD: Polite though. -- The Hitch-Hikers Guide to the Galaxy, Episode 11

[Michael]
If I may so bold, I suggest the distutils could use some (paid) tender loving care, too...
I know of a lot of other areas (my pet peeve: IDLEFORK). However, the scope of the current proposal needs to be limited to something that can be sold to the PBF as something that will significantly improve the quality of "conservative" releases (Python-in-a-tie, business release, name it what you want). Are there are specific platforms where distutils doesn't do the right thing? One of the PBF goals is also to have binary "sumo" distributions for many platforms (especially the platforms that commercial users love like Solaris, AIX and HP-UX). --Guido van Rossum (home page: http://www.python.org/~guido/)

On 22 May 2002 at 10:14, Michael Hudson wrote:
2) Not having this lunatic distinction between patches and bugs ...
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome? -- Gordon http://www.mcmillan-inc.com/

On Wed, 22 May 2002, Gordon McMillan wrote:
On 22 May 2002 at 10:14, Michael Hudson wrote:
2) Not having this lunatic distinction between patches and bugs ...
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome?
Well, I think it's the way bugs sometimes have patches attached to them, or sometimes a patch gets put in the patch tracker and a link to it posted in the bug tracker. I guess there is a distinction, but it's too high up on sf. You can't get a list of all issues assigned to one developer, for instance, or the fact that the "groups" field for the various trackers has diverged over much. I really could have done with a "2.2.1 issues" view -- instead I had to ping back and forth between bugs and patches. Etc. Does that explain my grievance? I can try harder if you want. Cheers, M.

"MH" == Michael Hudson <mwh@python.net> writes:
MH> Well, I think it's the way bugs sometimes have patches MH> attached to them, or sometimes a patch gets put in the patch MH> tracker and a link to it posted in the bug tracker. In fact, it is really hard to link issues in SF, especially if they span trackers. Add to it the fact that you have to know in advance whether an issue number is a bug or a patch (or a feature request) before you can search for it in the SF search box. www.python.org/sf helps with that, but it's still very inconvenient. -Barry

On Wed, May 22, 2002, Gordon McMillan wrote:
On 22 May 2002 at 10:14, Michael Hudson wrote:
2) Not having this lunatic distinction between patches and bugs ...
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome?
He's talking about SourceForge. If a bug has a patch, it should be directly part of the bug, not a separate PatchTracker submission. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In the end, outside of spy agencies, people are far too trusting and willing to help." --Ira Winkler

Aahz <aahz@pythoncraft.com> writes:
2) Not having this lunatic distinction between patches and bugs ...
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome?
He's talking about SourceForge. If a bug has a patch, it should be directly part of the bug, not a separate PatchTracker submission.
And indeed, on SourceForge, it can be directly part of the bug report. Regards, Martin

Gordon McMillan wrote:
On 22 May 2002 at 10:14, Michael Hudson wrote:
2) Not having this lunatic distinction between patches and bugs ...
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome?
i somewhat agree to michael. It becomes obvious when you want to submit a *patch for a bug* that you discovered. Even if reporting a bug and providing a patch is not done by the same person it's still one "issue" where the bug-submitter can help by testing the patch etc.. if-it's-not-a-bug-don't-fix-it-ly yours, Holger regards, holger

holger krekel <pyth@devel.trillke.net> writes:
if-it's-not-a-bug-don't-fix-it-ly yours, Holger
Tell that the submitters of the 50 or so patches for Python which don't fix bugs, but add features. Perhaps you can talk some of them into withdrawing their patch... Regards, Martin

Martin v. Loewis wrote:
holger krekel <pyth@devel.trillke.net> writes:
if-it's-not-a-bug-don't-fix-it-ly yours, Holger
Tell that the submitters of the 50 or so patches for Python which don't fix bugs, but add features. Perhaps you can talk some of them into withdrawing their patch...
For an appropriate definition of 'bug' they fix a bug. Seriously, even implementations of PEPs fix a bug in that the current behaviour is not how it *should* be. I guess the problem is that what some people think what *should* be in python is not what the core developers (or GvR at last) thinks. That's fine! The issue/feature/bug/patch should be rejected or at least deferred then. Why are the 50 or so patches still in the queue? holger

holger krekel <pyth@devel.trillke.net> writes:
Why are the 50 or so patches still in the queue?
There are 130 bugs in the back log (sf.net/projects/python), because nobody reviews them. This, in turn, is because there are no volunteers to try them out, and recommend patches for acceptal or rejection (or suggest improvements to the submitter). Some of the do fix bugs, so the 50 was an estimate. Regards, Martin

[Michael Hudson]
2) Not having this lunatic distinction between patches and bugs ...
[Gordon McMillan}
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome?
That they're in entirely distinct trackers. Would be much better if everything were in one tracker, with a bug-vs-patch-vs-feature tag for filtering displays. It's just extra work for everyone when, e.g., someone opens an SF bug in "the bug tracker" and then someone submits a patch to fix that bug in "the patch tracker". Now you've got two disconnected blobs (distinct URLs, distinct "id"s, distinct comments and descriptions, etc).

Gordon McMillan wrote:
2) Not having this lunatic distinction between patches and bugs ...
They seem distinct to me, but maybe I'm a bit old-fashioned :-). What artificial distinction do you find irksome?
As someone said, he's referring to the SF concepts. In Mozilla land, bugzilla is used for everything from bug management, patch management (it is the repository on which people indicate who'se reviewed what patch, when it was checked in, etc.), mailing-list-proxy and random banter (e.g. the "give hyatt $50" bug), user feedback mechanism (via bug voting, which AFAICT doesn't "work") as well as general project management. I think it's a lousy tool for project management, but then again I think all the tools I've seen are lousy tools for project management =). It is a feature that bugzilla is corruptible that way, one which would be good to have in the new system. The key low-level feature which enables this is keywords and a peer-enforced policy rather than rule-based policy (as in "_please_ don't change milestones if you're not part of the PDT team" or such). --david

On Wed, May 22, 2002, David Ascher wrote:
As someone said, he's referring to the SF concepts. In Mozilla land, bugzilla is used for everything from bug management, patch management (it is the repository on which people indicate who'se reviewed what patch, when it was checked in, etc.), mailing-list-proxy and random banter (e.g. the "give hyatt $50" bug), user feedback mechanism (via bug voting, which AFAICT doesn't "work") as well as general project management. I think it's a lousy tool for project management, but then again I think all the tools I've seen are lousy tools for project management =).
It is a feature that bugzilla is corruptible that way, one which would be good to have in the new system. The key low-level feature which enables this is keywords and a peer-enforced policy rather than rule-based policy (as in "_please_ don't change milestones if you're not part of the PDT team" or such).
Well, no, I don't agree with that last part. I'm all in favor of rolling all possible project tracking features into a single tool, but that doesn't mean one wants all features available to every user, and it especially doesn't mean that one wants all features available to every user for any specific subset of system records. For example, I think it's highly appropriate that if we use this system for actual project management that project goals assigned to a specific release get "locked" to everyone but Guido after Guido has approved assignment of that goal to that release. I think preventing stupid mistakes is an eminently reasonable use of the system. Which reminds me of another feature request: * CVS-like system rollbacks to defined states (minimum) or archiving of every change (preferred). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In the end, outside of spy agencies, people are far too trusting and willing to help." --Ira Winkler

On Wed, May 22, 2002 at 10:14:35AM +0100, Michael Hudson wrote:
1) An email interface (OK, so this has been said, and already exists, but...)
This is one of the things that really impressed me about the Debian bugs system. While it includes a web interface as well, it's primary mechanism of control is via e-mail. I haven't actually used it, but our LUG got a presentation on it a couple of months ago and I was very impressed. A few things I seem to recall: Submitting a bug/patch can be as simple as sending a plain text message without any special markup. Special name:value information can be provided if known (releases it's related to, etc)... All attributes can be changed, bugs/patches can be merged or split. Mailing "12345-submitter" (or the like) will send e-mail to the person who submitted but 12345. There are other aliases like that as well (mail people assigned to work on it, the automated system, etc). The Debian bug system is available at: http://www.debian.org/Bugs/ While I'm (not suprisingly) interested in roundup because it's in Python, I've been impressed with the demo of the Debian system. Sean -- "The big bad wolf, he learned the rule. You gotta get hot to play real cool." Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

Submitting a bug/patch can be as simple as sending a plain text message without any special markup. Special name:value information can be provided if known (releases it's related to, etc)...
I altered ActiveState's bugzilla to do this, although I dont think its such a good idea. By submitting through the web interface you can force people to give you certain data for example os, python version etc. You either end up getting inconsistent data or forcing emails to be written in a certain way. Once a bug is entered, sure send emails all you like. -- Andy McKay

"Andy" == Andy McKay <amckay@merlintechnologies.com> writes:
>> Submitting a bug/patch can be as simple as sending a plain text >> message without any special markup. Special name:value >> information can be provided if known (releases it's related to, >> etc)... When I last sent an unformatted bug to Debian, I got an autoreply saying "we have a 100GB bit bucket for this and it's about half full. If you don't want to wait your turn, you can really speed things up (and help the maintainer, too!) by formatting in the following way. Information at the following URLs [more detailed instructions, package search, the BTS URL] may be useful." More polite than that, but you get the idea. Worked for me. Andy> I altered ActiveState's bugzilla to do this, although I dont Andy> think its such a good idea. By submitting through the web Andy> interface you can force people to give you certain data for Andy> example os, python version etc. You either end up getting Andy> inconsistent data or forcing emails to be written in a Andy> certain way. True. I think the typical Debian package gets only a few entries a week. But I think a scoring mechanism that files the bug in a low-priority slot and bounces instructions back to the reporter is a good compromise. One thing I don't like about the Debian BTS is that it presents all unclosed bugs ever. Maintainers should have that in their face, I suppose, but from the user's point of view anything whose last entry is a year or more old is irrelevant. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
participants (12)
-
Aahz
-
Andy McKay
-
barry@zope.com
-
David Ascher
-
Gordon McMillan
-
Guido van Rossum
-
holger krekel
-
martin@v.loewis.de
-
Michael Hudson
-
Sean Reifschneider
-
Stephen J. Turnbull
-
Tim Peters