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

Reply via email to