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.