>> This is why things need to go into public trackers, or wiki pages.
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 [EMAIL PROTECTED] Skip -- http://mail.python.org/mailman/listinfo/python-list