On Sun, 30 Oct 2011, Graeme Gill wrote:

> You can't on the one hand keep saying "patches welcome" whenever someone
> requests a new feature (which is what happened last time someone asked for
> pop3 delete), and on the other hand come back weeks after you get such a
> patch contributed, and drop them on the ground. You are simply sending a
> strong message of "don't bother trying to contribute to libcurl".
>
> In this particular instance, you might have at least picked up my patch as a
> starting point to solve the bug at hand, thereby fixing two problems in one
> go.

Thank you for your advice, but I think you forget a lot of things here.

I do this on my spare time.

I don't claim that I or anyone else involved in this project work in an
optimal way, if you have ideas on how to improve the workflow please tell us.
But be prepared that just telling us how to behave without at least putting up
parts of the effort yourself is pointless.

You mailed your patch in the middle of my summer vacation, when I got back I
had a huge backlog that took me a good while to get through. I also
occationally miss/forget items but I at least *did* get back on the topic. I
do make a serious effort to not let (serious) issues slip through without at
least me responding.

I want involvement from others and I *MUCH* rather comment and provide
feedback on a patch and let the original author work on a next version to
provide it to us rather than putting that load onto my existing pile of work.
It seems much smarter to use more people rather than less.

I wasn't the only one who could've provided feedback. And some of the feedback
you could already figure out yourself by reading
http://curl.haxx.se/dev/contribute.html

If you just check our git or mailing list activity, you can quite clearly see
that we accept a large number of patches from others and that we also
contanstly work with lots of people's patches and bug reports.

I spend a few hours on curl every day, 7 days a week. I never reach the bottom
of my backlog so I need to prioritize. I favour issues where the
author/submitter/reporter works with us on the issue, other factors include
what picks my personal curiosity and issues that I think I can make a
differences in, as lots of the smaller/simpler issues can easily be done by
someone else without the particular insight or experience that I possess.

If I don't get any response to follow-up questions and responses, then that
issue often gets less focus from me until the responses come. Sometimes lack
of getting back to the topic is enough for me to just drop it completely with
the full knowledge that sure we sometimes drop real bugs this way, but I
cannot take on everything myself and if things are truly important they will
float back up to the surface again eventually.

Finally, I must add that I don't understand what you found so offensive in my
critique of your patch or how it has (not) been handled. You clearly addressed
at least one bug, but added features in the same patch in a way I dislike. You
probably could've fixed this into two separate patches in no time, and if you
really thought that your approach was the correct one and that I am wrong in
disliking it, then you shoul've argued that on this list with words explaining
your view.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html