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.
mail vs GitGub
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 30 Mar 2022 09:15:49 +0200 (CEST)
On Tue, 29 Mar 2022, Drew DeVault via curl-library wrote:
> I am not demanding special treatment. Contributions via email are accepted
> per the cURL developer documentation.
They are and we have obviously accepted your patches over mail more than once
already.
> I just used one of the options which was available to me according to my
> preferences. If this ran into problems with the process, the process should
> be improved.
I'm sure all our processes can be improved and so can this.
But it's not a "you and we" situation here, it's just "we". And for this "we"
to work on impriving this situation there has to be a good faith effort from
everyone involved and in particular those who want a change need to push and
drive for that to happen.
We get patches over email contributed every once in a while. It would estimate
that less than one in hundred pull-requests are done over email. I have
*never* before experienced a problem when I've helped those uses by pushing it
to GitHub and then continued to work on those patches in a hybrid mail/PR way.
It has not been a problem. Before.
We recently surpassed 1,000 commit authors and now there's one who refuses to
even browse GitHub. With one author in a thousand, this is not a big issue for
the project even if it might be for you. It might explain why we don't have an
elaborate setup working for this scenario. Nobody has offered or botered to
work on it.
> If cURL indeed does not wish to receive changes via email, the documentation
> should be updated.
We accept changes over email. We always did. We still do. It's a less
automated system and much less effective, but we still do it.
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.
Because as I already said: it has never been a problem before and we've been
doing pull-requests since 2015.
> 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.
> It's quite easy to apply my patch via email -- it's not necessary to route
> it through a GitHub pull request at all.
Right now and for the foreseeable future, it is a mandatory step in getting
anything merge into curl since the > 100 builds and tests are only done then.
> It's also possible to add tooling like CI to mailing lists, much like it was
> added to the GitHub repository.
I have never seen it done to even a half-baked degree of the same level and
effectiveness as we do it now on GitHub. And so far no one else has insisted
or even suggested we do. It feels like a lot of effort to please very few
developers. I'm don't see myself working on that anytime soon.
Date: Wed, 30 Mar 2022 09:15:49 +0200 (CEST)
On Tue, 29 Mar 2022, Drew DeVault via curl-library wrote:
> I am not demanding special treatment. Contributions via email are accepted
> per the cURL developer documentation.
They are and we have obviously accepted your patches over mail more than once
already.
> I just used one of the options which was available to me according to my
> preferences. If this ran into problems with the process, the process should
> be improved.
I'm sure all our processes can be improved and so can this.
But it's not a "you and we" situation here, it's just "we". And for this "we"
to work on impriving this situation there has to be a good faith effort from
everyone involved and in particular those who want a change need to push and
drive for that to happen.
We get patches over email contributed every once in a while. It would estimate
that less than one in hundred pull-requests are done over email. I have
*never* before experienced a problem when I've helped those uses by pushing it
to GitHub and then continued to work on those patches in a hybrid mail/PR way.
It has not been a problem. Before.
We recently surpassed 1,000 commit authors and now there's one who refuses to
even browse GitHub. With one author in a thousand, this is not a big issue for
the project even if it might be for you. It might explain why we don't have an
elaborate setup working for this scenario. Nobody has offered or botered to
work on it.
> If cURL indeed does not wish to receive changes via email, the documentation
> should be updated.
We accept changes over email. We always did. We still do. It's a less
automated system and much less effective, but we still do it.
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.
Because as I already said: it has never been a problem before and we've been
doing pull-requests since 2015.
> 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.
> It's quite easy to apply my patch via email -- it's not necessary to route
> it through a GitHub pull request at all.
Right now and for the foreseeable future, it is a mandatory step in getting
anything merge into curl since the > 100 builds and tests are only done then.
> It's also possible to add tooling like CI to mailing lists, much like it was
> added to the GitHub repository.
I have never seen it done to even a half-baked degree of the same level and
effectiveness as we do it now on GitHub. And so far no one else has insisted
or even suggested we do. It feels like a lot of effort to please very few
developers. I'm don't see myself working on that anytime soon.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-03-30