Re: git: 67783db661f8 - main - CONTRIBUTING: request only one submission type per change

On Tue, Apr 23, 2024 at 1:02 PM Gleb Smirnoff <glebius@freebsd.org> wrote:

>   Lexi,
>
> On Thu, Apr 18, 2024 at 08:27:56PM +0100, Lexi Winter wrote:
> L> as a non-committer src contributor, i've discussed this with imp@ quite
> L> a bit and i think this should be phrased more strongly in favour of
> L> using GitHub for commits.
> L>
> L> the current situation is that Phabricator is useless for non-committers
> L> because 1) you have to know who can review your commit, and 2) once your
> L> commit is reviewed, someone has to commit it, and Phabricator doesn't
> L> address this.
>
> The 1) is actually not as bad.  Phabricator has subscribtion hooks, and
> many
> committers have rules installed to get notifications of new reviews that
> touch certain paths of code.
>

Except we have really crappy coverage in phabricator from the herald rules,
so external submitters usually don't even get a 'hey we got it' feedback
from
the submission.... networking gets good reviews, ports get decent reviews,
some other select areas are OK... but on the whole, random submissions just
disappear here.


> The problem 2), IMHO, equally applies to github and Phabricator.
>

I can land a github PR in < 5 minutes. I can find all the open ones and
make sure they are progressing. The tools to automate this are easy
to write. I keep refining to reduce this time and push more automation
into useful places. We've not even begun to explore what we can
do in this space.

With Phabricator, though, it's impossible to find things that are
languishing,
landing them is much harder, and there's no clear set of responsibility
for doing something with it. Plus, Phorge doesn't really address these
concerns...


> L> i think it might make more sense to suggest that people submit all
> L> patches via either GitHub or Bugzilla, and only use Phabricator if
> L> specifically asked to.
>
> I don't agree here. Looks like we should address those phabricator
> submissions that go unnoticed due to lack of maintainers of a code.
> I don't think submitting same patch to github will improve visibility.
>

I've put a ton of energy into that... Good luck. I'm done trying
because it's too hard. I can't even easily do a query for 'Find me
all the stalled requests'. Or 'find all the ones I tagged as interesting'
or half a dozen other things that are necessary to manage the queue.
And lots of people (myself included) have been bad about closing
out the stale requests, making the problem even worse. While specific
queries can be written to address my concerns, they are so tightly
focused that I can't refine them at all (since the criteria for selection
isn't in the search interface). It's a mess, and not likely to get better.

So until the "disappearing into phab" is fixed, we should concentrate
on github pull requests. I've had good luck tagging the right people
on github of late... and most of the submissions, frankly, don't require
a lot more than a quick once-over to know if it's good or not. There are
some that have languished, though, due to this lack... But I've learned
to pull people in earlier in the process rather than letting it languish.

So respectfully, I'd like to leverage the little bit of github pull request
success we've had, reserve phabricator for the 'exception path' when
something needs actual review from a developer who will take the
responsibility to either commit or explicitly reject the phab review than
to pin our hopes on making phabricator easier to use first.

Warner