Date: Mon, 30 Jan 2023 05:52:41 +0000 From: User Ngor <ihor@antonovs.family> To: freebsd-current@freebsd.org Subject: Tooling Integration and Developer Experience Message-ID: <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> In-Reply-To: <202301300254.30U2sm0k061914@dell.no.berklix.net> References: <202301300254.30U2sm0k061914@dell.no.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/30/23 02:54, Julian H. Stacey wrote: > Jamie Landeg-Jones wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix >> to an admittedly trivial issue, but it's soon going to hit one year old, >> and has not had any feedback. Not even "this is rubbish. close ticket" >> >> | jamie@catwalk:~ % stat 'so good they named it twice' >> | stat: so good they named it twice: stat: No such file or directory >> >> As such, it's the oldest of my patches to be completely ignored, but then, >> most of my fixes I haven't even submitted, because, what's the point? >> I've instead spent time writing something so the patches are automatically >> aplied to my src tree, and distributed to all my servers. Forked from: 1 year src-patch anniversary. I feel Jamie's pain, this kind of experience can be very discouraging to any contributor without commit bit. All developers like quick feedback loops. Nobody wants to wait a year. I think FreeBSD project looses a lot of potential contributors due to issues of this kind. I don't believe there is any ill intent, there is no elite cast of grumpy commit-bit holders who only work on what they are interested in, ignoring the project as a whole. Far from it. But I do hope that the situation can be improved and I want to offer my view and opinion. The Problem ----------- I do believe that the source of all problems is lack of integration in tooling and communication. Let me elaborate: FreeBSD project has a lot of tools, but the tools are not well integrated together: - There are too many places where a patch can be posted: phabricator, github, bugzilla, mailing list. - There are too many places to have a conversation: mailing lists, phabricator reviews, bugzilla comments, github issues and PRs, forum, multiple IRC channels spanning multiple IRC servers, etc. - A posted patch is cat in the bag, there is no pre-commit CI to do some basic sanity-checking, commit-bit holders need to do a lot of work to verify the commit (run CI on it) - Tools are not integrated. There is no information flow between them, no effective cross-referencing, lookup or discover, etc. - Bugs in Bugzilla are not visible in Phabricator. - Commits in Phabricator do not resolve bugs in Bugzilla - Jenkins CI/CD and Phabricator don't know about each other. ... there are probably more examples, but this is enough to draw a few conclusions: 1. Information is fragmented and is easily lost or forgotten. 2. It takes manual human effort to update information in multiple systems. 3. Human attention (developers, contributors, etc.) to different systems is spread unequally. This leads to poor developer experience, regardless of commit-bit status. A patch posted in bugzilla went unnoticed for a year until frustrated and desperate contributor started complaining about it in the mailing list, and was committed hours later. The is also a lack of designated maintainers (I am drawing the analogy from Linux kernel) A role who's job is to integrate: collect all patches, feedback, reports about a specific area (kernel subsystem, userland tool or whatnot), and update/curate the knowledge and communication around this area. In my 15+ year career in IT I've seen multiple projects fail due to communication and integration issues. Without concentrated effort and strong leadership these problems rarely go away on their own. Proposed Solutions ------------------ In the order of implementation: 1. Tooling integration: This can be as easy as moving everything into Phabricator. Phabricator, apart from features that we already use, has support for CI/CD, bug reports, wiki, project planning and milestones, chat, etc. Alternative platforms can be used as well: GitLab, SourceHut The main idea: to prevent information fragmentation and improve discoverability, cross-referencing abilities, search, etc. The challenge: is inertia and migration of existing information out of currently used tools. The sentiment: we don't need more tools, we need fewer tools that work better together. 2. Growing the community: Integrated tooling improves productivity and allows focusing on quickening the feedback loop: accepting/rejecting/commenting one-off contributions faster. Regular contributors will be more visible and will get commit-bit faster. With enough commit-bit holders focused maintainership practice can be started. In the end this is just my opinion, I hope it will spark some conversation. Thanks for reading this far :) -- Ihor Antonov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97020cad-f913-2985-2093-e4c23bf671e3>