Re: Tooling Integration and Developer Experience

On Mon, Jan 30, 2023 at 3:40 AM Kurt Jaeger <pi@freebsd.org> wrote:

> Hi,
>
> > > On 1/30/23 02:54, Julian H. Stacey wrote:
> > >    The main idea: to prevent information fragmentation and    improve
> > >    discoverability, cross-referencing abilities, search, etc.
> >
> > With regards to improving discoverability, Phabricator's Owner
> > tool could be a good tactical move: it allow to bind code area to
> > peoples in order to automatically add them to reviews.
>
> If you know phabricator in more detail, is there any kind of tool
> to understand the activity going on ?
>
> In bugs.freebsd.org, there is the dashboard:
>
> https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html
>
> I think we might need something similar to help us understand
> the current state of the phabricator instance and the work
> being done.
>
> Phab allows Dashboards, but no-one had the time to configure some
> queries to provide relevant stats.
>

Phab is a terrible tool for discovery. For example, how do I query all the
reviews I've ticked 'OK' that are still open, by non-committers? How do I
flag things as 'interesting to me'? I can tick a flag, but I can't query
flags. Also, I can't get an email address for submitter either. That makes
it more of a pain to land the commit.

Buzilla is in many ways worse (it's absolutely terrible for doing code
reviews, though it's queryability is much better). In some ways it's better
for changes that are ready to go, since you can upload git format-patch
output, but it too has discoverability issues.

Github and gitlab pull requests are better in some ways, but worse in
others. The review tool isn't as good as phab, and when you have a lot of
them, they are hard to organize. But it's my preferred way to land patches
because it's absolutely the easiest from a developer point of view to do
so: It's one command (though the commands differ between the two).

The foundation is funding the CI aspect of this: Getting jobs that
developers and automation can run to gate in place. Until we have that in
place and integrated together, things will be harder.

But there's two other issues: The FreeBSD project has had a long history of
being behind, regardless of the tools we use. There's a labor shortage to
process these things as well. Second, lots of people want to talk, but few
want to do the work. I tried leading an effort in this area,but grew weary
of the passive-aggressive comments about how I basically sucked for not
having it done already (from the same people that did 0 actual work on it).

Warner