Submitting Bugs at Sourceforge

Tim Peters tim.one at home.com
Sun Apr 22 15:20:19 EDT 2001


[Stephen]
>     I'm in the process of working on the Python-2.1 sources to make them
> compile from Borland C++Builder, since it has a free compiler out there
> and all.

Cool!

> ...
>     Now, my question: I submitted 4 bug-reports on the various minor
> fixes that needed to be done, and have 4 left that I havn't sent in
> yet. Just in general, would it be better for me to send in a batch of
> those little fixes, or submit each one as a seperate bug report? For
> the most part, they're changing various #defines which at the moment
> assume Win32 = Visual C++.

Patches are much better than bug reports, if you can make a patch:  when you
merely describe what you need in English, it's time-consuming to deal with
the description, and the person who (therefore reluctantly <0.9 wink>) takes
it on has NO WAY to tell whether their interpretation of what you wrote
actually fixes the problem on your platform.

If you can't make a patch, second best is to gather up *all* the changes you
need, stick the new versions of the files on the web, and submit one patch to
SourceForge containing URLs to the new files.  It would actually be better to
upload the new files as attachments to the patch, but SourceForge has a low
limit on the size of file attachments so that may not work.

Next best is to email the new files to me directly:  since you're fiddling
with PC\config.h, I have to test the changes anyway to guarantee they don't
break the non-Borland Windows builds.

A caution in advance:  there are some things we won't accept anymore.  Python
requires an ANSI-conforming C compiler now, and changes that seek to #ifdef
their way around broken compilers and libraries have a good chance of getting
rejected, especially if it's a compiler relatively few people use
(historically, people using "challenged" compilers submit patches and then
vanish, and nobody remains who can fix the new bugs introduced when the old
bugs in the platform compiler eventually get *fixed*).





More information about the Python-list mailing list