Enrico - thanks for sharing your experience.
I recently got a couple of PRs merged and my experience was different. I
got lots of feedback from several maintainers (thank you very much!).
Can't speak to your PRs specifically, but can give the general advice that
pivoting code based on maintainer
Yes, committers are added regularly. I don't think that changes the
situation for most PRs that perhaps just aren't suitable to merge.
Again the best thing you can do is make it as easy to merge as possible and
find people who have touched the code for review. This often works out.
On Tue, Feb 23,
Am 18.02.21 um 16:34 schrieb Sean Owen:
One other aspect is that a committer is taking some degree of
responsibility for merging a change, so the ask is more than just a
few minutes of eyeballing. If it breaks something the merger pretty
much owns resolving it, and, the whole project owns any c
Enrico - do feel free to reopen the PRs or email people directly, unless you
are told otherwise.
On Thu, Feb 18, 2021 at 9:09 AM, Nicholas Chammas < nicholas.cham...@gmail.com
> wrote:
>
> On Thu, Feb 18, 2021 at 10:34 AM Sean Owen < srowen@ gmail. com (
> sro...@gmail.com ) > wrote:
>
>
>>
On Thu, Feb 18, 2021 at 10:34 AM Sean Owen wrote:
> There is no way to force people to review or commit something of course.
> And keep in mind we get a lot of, shall we say, unuseful pull requests.
> There is occasionally some blowback to closing someone's PR, so the path of
> least resistance i
On Thu, Feb 18, 2021 at 9:58 AM Enrico Minack
wrote:
> *What is the approved way to ...*
>
> *... prevent it from being auto-closed?* Committing and commenting to the
> PR does not prevent it from being closed the next day.
>
Committing and commenting should prevent the PR from being closed. It m
Holden is absolutely correct - pinging relevant individuals is probably
your best bet. I skim the 40-50 PRs that have activity each day and look
into a few that look like I would know something about by the title, but,
easy to miss something I could weigh in on.
There is no way to force people to
Git blame is a good way to figure out likely potential reviewers (eg who’s
been working in the area). Another is who filed the JIRA if it’s not you.
On Thu, Feb 18, 2021 at 6:58 AM Enrico Minack
wrote:
> Hi Spark Developers,
>
> I have a fundamental question on the process of contributing to Apa
Hi Spark Developers,
I have a fundamental question on the process of contributing to Apache
Spark from outside the circle of committers.
I have gone through a number of pull requests and I always found it hard
to get feedback, especially from committers. I understand there is a
very high com
