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.
Which PRs should we merge?
- 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: Tue, 24 May 2022 17:08:37 +0200 (CEST)
Hi friends,
We have several pull requests in the queue that are in good shape for
inclusion, that I fear lack a *need* and *desire* from the community.
I don't think we should adopt new features just because someone wrote an
excellent PR for them but I also don't want to reject things just because the
feature doesn't make me personally excited.
I end up feeling presure to merge (and I feel bad for the authors I "leave
behind") and I bet PR authors get upset with me when I hesitate and *don't*
merge PRs that are fine in all other aspects.
Can we come up with a way to make this better?
Here's a thought: what if we create a new label, say "needs-votes" (exact name
to be decided) that we can set on PRs that we feel have not yet been clearly
indicated as "desired by the community".
Such PRs will need, let's say 5 (to start off conservatively), thumbs-up votes
on GitHub before they can be merged. That way we presumably know that at least
5 "separate" users want the feature in curl. We could of course also allow
thumbs-down for "I really don't think this should be merged".
That's just an idea. Any better ones?
Date: Tue, 24 May 2022 17:08:37 +0200 (CEST)
Hi friends,
We have several pull requests in the queue that are in good shape for
inclusion, that I fear lack a *need* and *desire* from the community.
I don't think we should adopt new features just because someone wrote an
excellent PR for them but I also don't want to reject things just because the
feature doesn't make me personally excited.
I end up feeling presure to merge (and I feel bad for the authors I "leave
behind") and I bet PR authors get upset with me when I hesitate and *don't*
merge PRs that are fine in all other aspects.
Can we come up with a way to make this better?
Here's a thought: what if we create a new label, say "needs-votes" (exact name
to be decided) that we can set on PRs that we feel have not yet been clearly
indicated as "desired by the community".
Such PRs will need, let's say 5 (to start off conservatively), thumbs-up votes
on GitHub before they can be merged. That way we presumably know that at least
5 "separate" users want the feature in curl. We could of course also allow
thumbs-down for "I really don't think this should be merged".
That's just an idea. Any better ones?
-- / 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-05-24