I have never refused to browse GitHub, though I would empathise with someone who did not wish to. However, it is much more challenging to receive feedback on emailed patches via GitHub. Initially I did not understand that part of your feedback was in the form of amending my patch, so I didn't pick up your changes when submitting a new revision. Later, I did not receive any notifications when you made additional changes on GitHub, and I was unaware that I should go and check that again.
It seems like this discussion has gotten well out of hand. There's no cause for any antagonism from anyone, including me, and including Daniel, in this discussion. I apologise for my part in the communication errors, but I do not feel that I am being given a fair rub here. I am in full agreement (moreso than you may realize) that FOSS development is an "us", not a "you and we". But that requires trust, patience, and the presumption of good faith from both sides, and I'm not sure I'm receiving any of these. On Wed Mar 30, 2022 at 9:15 AM CEST, Daniel Stenberg wrote: > But nowhere in that offer does is say that we will also pass back every > comment, improvement and CI job output to the mailing list when the patch is > converted into a pull-request by someone. It is not your responsibility to do this, and I of course understand this. But rather than meekly accept this as my fault for not checking GitHub every time I prepare to send a new patch, I want to interrogate the process to find out how this can be prevented when the next person comes along. This is a kind of contribution to cURL: looking closer at process with the perspective of an edge case. The process is not God, and we can critically examine it and figure out how to improve it so that it works better for everyone. My aim is not shifting responsibility, but improving the process. > > Prior to moving to GitHub, many curl patches were submitted via email. curl > > is much older than GitHub, after all. The state of affairs prior to the > > move > > sufficed for almost 20 years. > > But did it suffice, really? > > Review, LOTS of before-merge testing, CI, verification, comments and more > have > improved to levels that were completely unreachable before 2015. > > Sure it worked before, but we've come so much further now. Yes, because you have invested in these things on GitHub. You could have also invested in these things on email. And yes, I understand where that investment has to come from - me, and others who care about contributing via email. I'm not insisting that "you" do anything, but talking about what the "project" should do -- a project which, in this turn of language, serves as the inclusive "we", as you suggest. And as I mentioned elsewhere in the thread, I wrote the tool that Alpine Linux uses to sync GitLab with their mailing list - I probably have some useful insights to add to mailing list process discussions! Honestly, though, this entire thread has become a massive fuck-up thanks to mistakes on the part of everyone involved, and now that feelings have been hurt there's probably not really anywhere to go from here. I'm going to abandon my patch, which was only to facilitate a temporary hack on my end anyway. This was not a good way for this to end. -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
