Submitting Bugs at Sourceforge

Stephen news at myNOSPAM.org
Sun Apr 22 22:51:53 EDT 2001


"Tim Peters" <tim.one at home.com> wrote in message
> >     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.

    Alrighty, I'll get a clean download of the sources and re-put in my
changes and make some patches. The problem is -- How does one make patches
in Windows? I know diff from back when I ran FreeBSD, but I can't quite find
a utility to do so under windows. My Visual C++6 has a 'Windiff', which
looks rather braindead and seems to just be FYI and not functional for
making patches.
    Besides not knowing where a windows diff/patch was, the reason I wasn't
sending patches is because I am not as of yet too familiar with the Python
sources, so am not entirely sure on the 'correct' way to make the fixes. For
instance, as you are aware, I didn't realize 'pyport.h' existed. *grin*

> 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*).

    All the changes I make should be ANSI C compliant; I was actually having
Borland compile in 'ANSI' strict mode until I got tired of it being
silly-ily strict over // comments and puking them out on a couple
occassions. Everything needed to be fixed has been in one of the two
categories:

    A) Simply adding/removing HAVE_* defines which are not appropriate for
Borland.
    B) Renaming a few functions. Irritatingly, whenever Microsoft names
something '_function', Borland names it 'function', and whenever Borland
names something '_function', Microsoft names it 'function'. Hmph!

    So the fixes shouldn't be anything that would concern you, as far as
ANSI compliance goes.

Thanks for the help!

--Stephen
(replace 'NOSPAM' with 'myseraph' to respond in email)





More information about the Python-list mailing list