Hi everyone,
Hi all,
the GitHub PR topic popped up from time to time on IRC in the past but
it seems we never discussed it here or came to any conclusion that led
to action.
When we switched to Git, we wrote down three ways to send patches [1]:
o Via our mailing list
o Via gerrit on coreboot.org
o Via pull request on flashrom's github mirror
If the repo on github is a mirror which tracks the "master repo" in coreboot, it does not make sense to use pull requests, as they would land on the mirror.
I have never reviewed on the mailing list, so I don't know how tedious it is. In any case, it's easier to move mailing list patches to gerrit than pull requests.
Now, roughly 2 years later, some PRs have been merged, but some, even
smaller ones, were left unanswered. We also never set a clear process
how to move things to Gerrit.
Agreed. Should we stop accepting pull requests, it would be good to document (or link to) the procedure to create a change on gerrit.
While I still don't object to reviewing on Github, if somebody wants
to do so, it has some downsides: no global overview of pending patches,
no build testing before moving things to Gerrit, the overhead of moving
things, ofc (IMHO, reviewing on Github is also much harder, maybe I'm
just Gerrit spoiled).
IMHO, handling the merging of pull requests alone is cumbersome enough to outweigh the benefits of allowing pull requests.
Especially the build-test integration makes it hard for me to come up
with a reasonable process. Hence, I suggest that we just stop accepting
PRs on GitHub and tell contributors to push to Gerrit directly. This
may be more work for the contributors and might even scare some away;
but I don't see any lack of contributions to this project rather a lack
of reviewer resources. So we should make reviewing as easy as possible,
IMO.
I completely agree.
Best regards,
Angel Pons