Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: mail vs GitGub
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Drew DeVault via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 30 Mar 2022 09:41:44 +0200
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.
Date: Wed, 30 Mar 2022 09:41:44 +0200
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.htmlReceived on 2022-03-30