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.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
