François> Whatever means the maintainer wants to fill his preservation
François> needs, he is free to use them. The problem arises when the
François> maintainer wants imposing his own work methods on others.
François, that's not it at all. It's not our fault that SF doesn't support
email-based tracker interaction. It's our fault that we chose SF, but it
was the best overall choice at the time (there were more considerations than
just bug tracking) and now we're sort of stuck with it because for a number
of reasons we've been unable to move away from it.
Here's the scenario we have to use today to collect emailed requests and put
them in SF:
* Kind user notices a problem and posts a message somewhere, maybe to c..l.py
or to another Python-related list or by direct email to a developer.
* Someone - maybe nobody, but maybe more than one person - notices the
request and thinks, "better add that to SF so it doesn't get lost".
* That person visits SF and submits a ticket.
Now, consider some of the problems this scheme is fraught with:
* Maybe nobody notices it at all. It might have been buried deep in another
thread that no Python developer happened to read in its entirety. Bummer.
It's been lost until the next time someone notices and posts a similar
request.
* Maybe more than one person notices. Bummer. Now we have duplicates.
Worse yet, some might have been posted as feature requests, some as bug
reports. It also may not be obvious that they are duplicate without
careful checking.
* The multiple reports might contain different useful perspectives on the
problem. Bummer. SF doesn't allow you to easily merge two requests. You
have to manually transfer the information from one to the other and close
the one.
* Maybe the original post generates further responses in that venue that
would have been useful to have with the original report. Most will
probably never find their way to the tracker. Bummer. They got lost..
* Maybe the original requester's email gets missed in the process (or the
problem isn't addressed immediately and the user has discarded the
original address because it's spammed so heavily and moved on to a new
one) and the Python developers need more info but they can't contact the
requester. Bummer. The problem isn't adequately addressed.
* Finally, instead of one person spending a couple minutes submitting a
report, several people will have spent their volunteer time, and there's a
good chance that the report is not any better (perhaps even worse) than if
the original requester had simply submitted the request directly to SF.
I know, we have to take these steps occasion. When bug reports have to be
moved from another tracker to the Python tracker some of these issues arise.
We've incorportated bug reports from the Debian bug tracker that way and
have migrated python-mode requests from the Python project to the
python-mode project (both on SF). It can be a pain.
The Python developers are not being lazy. I would love it if there was an
email interaction mode with the SF trackers, but there isn't. I'll repeat
what I wrote yesterday in response to an earlier message in this thread:
I wish either a) SourceForge supported email interaction with their
trackers or b) someone would finish off the Roundup issue tracker
<
http://roundup.sourceforge.net/> for python.org. I doubt if anyone
here can do anything about the first barrier, but if you know something
about Roundup (or would like to learn about it) and would like to
contribute something non-documentational that would really have a
direct, positive impact on the Python community, send a note to
(e-mail address removed).
Skip
