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: Which PRs should we merge?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 25 May 2022 03:33:27 -0400
On 5/24/2022 11:08 AM, Daniel Stenberg via curl-library wrote:
> 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".
Frankly I think that's a fine reason to reject things. Sometimes there
just isn't enough feedback and none of us are particularly excited about
it. I don't think a formal 5 user vote system is a good way to get more
feedback on a PR but I do think we can make it better with more exposure
that a PR needs user feedback. I like an idea elsewhere in the thread to
make a list that is sent out periodically identifying those threads. In
some cases you or I have already done this for individual PRs. Often
there is no additional feedback.
Date: Wed, 25 May 2022 03:33:27 -0400
On 5/24/2022 11:08 AM, Daniel Stenberg via curl-library wrote:
> 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".
Frankly I think that's a fine reason to reject things. Sometimes there
just isn't enough feedback and none of us are particularly excited about
it. I don't think a formal 5 user vote system is a good way to get more
feedback on a PR but I do think we can make it better with more exposure
that a PR needs user feedback. I like an idea elsewhere in the thread to
make a list that is sent out periodically identifying those threads. In
some cases you or I have already done this for individual PRs. Often
there is no additional feedback.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-05-25