Date: Mon, 30 Jan 2023 15:28:50 +0100 From: Dmitry Salychev <dsl@mcusim.org> To: Warner Losh <imp@bsdimp.com> Cc: Kurt Jaeger <pi@freebsd.org>, Stephane Rochoy <stephane.rochoy@stormshield.eu>, freebsd-current@freebsd.org Subject: Re: Tooling Integration and Developer Experience Message-ID: <867cx4ozic.fsf@peasant.tower.home> In-Reply-To: <CANCZdfpPfzN%2B8nVEkRPAw2sC-W=QaUp851KcwRpJwg1zneFPNA@mail.gmail.com> References: <202301300254.30U2sm0k061914@dell.no.berklix.net> <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> <86357sxsly.fsf@cthulhu.stephaner.labo.int> <Y9eepV%2B%2Bch6qMBta@home.opsec.eu> <CANCZdfpPfzN%2B8nVEkRPAw2sC-W=QaUp851KcwRpJwg1zneFPNA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@bsdimp.com> writes: > 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 I'd want to express an obvious idea (sorry for that!), but from the newcomer's point of view, it's significantly easier to take care of those parts of code which he wrote or patched himself at least. As the FreeBSD project carries its legacy which is rather burden in this particular case, why not to prepare a plan of the small steps in order (a) to improve committer awarness of the changes in "their" code and (b) not to consume a lot of people's time? You can think about it as tweaking of the existing tools like Phabricator and Bugzilla instead of adopting new ones. -- Dmitry Salychev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?867cx4ozic.fsf>