Re: [PATCH v4] setopt: make curl_easy_vsetopt public

From: Timothe Litt <litt_at_acm.org>
Date: Tue, 29 Mar 2022 07:11:42 -0400

On 29-Mar-22 03:39, Drew DeVault via curl-library wrote:
> On Tue Mar 29, 2022 at 9:32 AM CEST, Daniel Stenberg wrote:
>> I'm sorry, but whose job would you say it is to forward outputs from GitHub CI
>> jobs from your patch to the mailing list because you won't go there and check
>> yourself?
> I would say it's the project's responsibility to make the contribution
> process as smooth as possible. lists.sr.ht facilitates forwarding CI
> results to mailing lists, for instance. You've made contributions via
> email a second-class citizen, thus my feedback on the process. I have no
> desire to use a nonfree platform like GitHub to contribute to curl.

I'm not a core member of the project, and don't speak for it.

But it's not clear what point you're actually making by refusing to use
github.

Yours is the only material contribution to curl that I've seen done via
e-mail.  And it's not a particularly big change.

You're not avoiding the use of github - all you're doing is using it
indirectly - and in the process, consuming the time of its primary
developer as an intermediary.  So how is this influencing github to
change?  It's seeing the same number of commits, the same number of pull
requests, the same usage of CI as if you made the commits directly.  Or
maybe a bit more if the e-mail path introduces any errors.  You've
deprived github of a user account - which, since the same work is being
funneled through an intermediary, only reduces their costs.  On the
other hand, you've made it more expensive for the curl project to accept
your contribution.

This man-in-the-middle approach to patching isn't scalable - in # or
size of patches without adding/diverting scarce resources. You're
already on version 5 of a trivial (compared to, for example, adding a
new protocol) change.

I think it's great that you found something to contribute.  And it's
nice that the project has bent over backwards to accommodate your
whims.  I don't think that requesting that the project invest in making
things even easier for you is reasonable.  While every contribution has
some value, how many would be lost if it doesn't?  There has to be some ROI.

I'm well aware that other projects do use e-mail submission effectively
- to a 'freer' repository.  They do this through extensive automation,
not manpower.  Persuading the project to move to such a
repository/CI/issue tracking system would be heavy lift, involve a
measurable opportunity cost, and so be a hard sell.

Nonetheless, if you really believe that e-mail-based contribution should
be a first class citizen, perhaps your next contribution should be
offering to implement *and maintain* the mechanics to make it so.  That
could be by migrating to a new "free" platform (unlikely to succeed), or
by interfacing to github (which doesn't align with your philosophical
goals).  And/or find a way to quantify the benefit to the project of
doing so.  How many potential contributors are discouraged by the
requirement to use github and would use e-mail (knowing that the backend
is still github)?  And how much/what would they be likely to contribute?

There are better ways to make your point.  I've found that the best way
to contribute to a project is to use whatever mechanism it provides, not
to demand special treatment.  (And for that reason, even though git is
dominant, I still have clients for many, many code management/version
control systems installed.)

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Received on 2022-03-29