On Tue, 21 Mar 2023 at 05:59, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2023-Mar-20, Thomas Munro wrote:
>
> This led me to suggesting that perhaps we need to be more lenient when
> it comes to new contributors. As I said, for seasoned contributors,
> it's not a problem to keep up with our requirements, however silly they
> are. But people who spend their evenings a whole week or month trying
> to understand how to patch for one thing that they want, to be received
> by six months of silence followed by a constant influx of "please rebase
> please rebase please rebase", no useful feedback, and termination with
> "eh, you haven't rebased for the 1001th time, your patch has been WoA
> for X days, we're setting it RwF, feel free to return next year" ...
> they are most certainly off-put and will *not* try again next year.
I feel like the "no useful feedback" is the real problem though. If
the patches had been reviewed in earlier commitfests the original
contributor would still have been around to finish it... Like, I think
what would actually solve this problem would be if we kept a "clean"
house where patches were committed within one or two commitfests
rather than dragged forward until the final commitfest.
I do agree though. It would be nice if it was easier for anyone to do
trivial merges and update the commitfest entry. That's the kind of
thing gitlab/github are better positioned to solve when they can have
integral editors and built-in CI...
I haven't been RwF or moving to the next commitfest when the merge
looked trivial. And in one case I actually did the merge myself :) But
that only goes so far. If the merge actually requires understanding
the patch in depth then the counter-argument is that the committer
might be spending a lot of time on a patch that won't get committed
while others sit ignored entirely.
--
greg