On 1/8/23 11:38, Jeff Epler wrote:
On Sun, Jan 08, 2023 at 04:06:07AM +0000, Chris Morley wrote:
I disagree with having to use pull requests for devs. (if I understood that
right)
We already have problems getting pull request reviewed and aproved.
I will not change this without consensus.
In the long run, though, successful projects are able to review and
merge (or, when necessary, reject) pull requests in a timely fashion. In
this respect, our project's health is poor.
I think that the way that "core developers" can simply ignore the pull
request process if they choose to do so contributes to this. These core
developers can both bypass this speed bump if they choose, and ignore
pull requests from others even where their expertise can accelerate the
PR's inclusion.
In other projects where I participate (incuding my work, which is all
public on github) working via pull request is the default. It works
well, and by numbers I believe that most PRs come from external
contributors but admittedly "the it works" depends on having ~4.5 paid
FTEs on the project. A small number of reviewers are able to make short
work of most PRs, especially when there's a culture of doing it. I spend
maybe 5% of my time reviewing PRs, while some of my colleagues probably
spend substantially more.
My work experience is varied. I've worked on larger teams where
everything went through the PR process (and folks treated new PRs as
high-priority interrupts), and on smaller teams where we all pushed
directly to the long-lived branches without review.
The ubiquitous use of PRs is beneficial for code quality and for team
communication, but it does introduce extra work, sometimes a significant
amount.
Some of the extra work falls on the folks reviewing PRs, but it's
important that the person *opening* the PR shoulder some of this burden
too: by writing small, clean commits with good descriptive commit
messages, and a good message in the PR explaining the high-level purpose
of the whole branch.
This is good practice anyway, and is part of our project guidelines,
though I sometimes get lazy and don't follow it:
<http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_effective_use_of_git>
I think beyond a certain project size the PR process becomes worth it.
I think we're well beyond that project size, and I would like to see us
at least try this.
If we can't make ourselves review each others' PRs in a timely fashion
the experiment will have failed and we can go back to the current "push
at will" workflow.
--
Sebastian Kuzminsky
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
