Qsort defects

[Joel Sherrill]

Nicely said Eric.  It really hit the nail on the head.

Your improvement is welcomed.  If you need pointers
on how to do a diff, just ask. Next time, it will be you
giving the advice. That's how open source works.

--joel
RTEMS

On 2/19/2013 9:07 AM, Eric Blake wrote:
> On 02/18/2013 03:20 PM, Eric Blake wrote:
>> On 02/18/2013 02:39 PM, Dennis de Champeaux wrote:
>>> I have been advised that this is the proper list// see below:::
>> You were also advised that attaching the new version of a file is not
>> the proper way to submit a patch; rather, you should attach the output
>> of 'diff -u broken fixed'.
>>
>> Looking at other patches on this list might be helpful on learning how
>> to properly submit a patch:
>> http://sourceware.org/ml/newlib/2013/msg00079.html
> On re-reading this message, I see that I may have come across harsher
> than intended.  Email is a lousy medium for conveying emotion.  So let
> me add an apology and the following additional information:
>
> First, a big thanks for taking the time to track down a problem, and to
> attempt to address it.  Open source works at its best when anyone,
> including first-time posters like yourself, can feel welcome to
> contribute their improvements.  Scratching your own itch, as you have
> done by investigating the poor performance of qsort, is encouraged.
>
> Second, this list is run mostly by volunteers.  I am not paid to
> contribute to newlib, but it is something I do in my spare time, and,
> like many others, I don't seem to have much of that.  In the open source
> world, you must remember that many of the list readers are doing so on
> their own time, and that anything you can do to make the maintainer's
> job easier makes it that much more likely that your improvements will be
> accepted.  If you submit something half-baked, and force a maintainer to
> spend 20 minutes to polish into a final product, you have cost that
> maintainer 20 minutes that they could have been doing something more
> productive; whereas if you submit something that already complies with
> list standards, the maintainer can spend less than a minute
> incorporating your work.  Since you are already familiar with the code
> you are fixing, it will take you less time to submit something perfect
> than it will for someone else to come up to speed to fix your
> submission.  In the open source world, receiving feedback that asks for
> a re-submission is a GOOD sign - it means that someone agreed with your
> analysis enough that they would like to help YOU do the additional work
> to get it incorporated.
>
> It may help to read the following:
> http://www.linuxchix.org/content/courses/kernel_hacking/lesson9
> While that page is more geared towards kernel hacking, and newlib is not
> quite as strict as the kernel folks, the points it raises are good food
> for thought - patches work best when the contributor makes life easier
> for the maintainer.
>
> So again, my apologies if I came across sounding mean or harsh, and I
> look forward to your resubmission according to list policy.
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985