From nobody Mon Jan 30 05:52:41 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P4y4v2L2Bz3bGWM for ; Mon, 30 Jan 2023 05:52:31 +0000 (UTC) (envelope-from ihor@antonovs.family) Received: from mail.antonovs.family (mail.antonovs.family [100.25.240.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.antonovs.family", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P4y4t6MB7z3Gl2 for ; Mon, 30 Jan 2023 05:52:30 +0000 (UTC) (envelope-from ihor@antonovs.family) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=antonovs.family header.s=20200215 header.b="x/5w/xG/"; spf=pass (mx1.freebsd.org: domain of ihor@antonovs.family designates 100.25.240.195 as permitted sender) smtp.mailfrom=ihor@antonovs.family; dmarc=pass (policy=none) header.from=antonovs.family DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antonovs.family; s=20200215; t=1675057945; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Es0I/t49LZzjl/ITYe30U6gzRD8w+LcPrJrBt8zxhB4=; b=x/5w/xG/WXRnGd5WzDcXcX8E5oyWZ/25J/Q5fBY4v6cs4ijJ6CzNCC8bDVV2rMSr7rYPnL 44a8TgGcDQkBQVV2poMQfXlJwh7KPTPjS4GRZ7nrSTW4wwuA0VHBv/6qtg2ZyF+YLA+nLw nWctLqAv5NQfEV3ZvzYaRaYzIlrXvwA= Received: by mail.antonovs.family (OpenSMTPD) with ESMTPSA id 30ae20df (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 30 Jan 2023 05:52:25 +0000 (UTC) Message-ID: <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> Date: Mon, 30 Jan 2023 05:52:41 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Tooling Integration and Developer Experience Content-Language: en-US To: freebsd-current@freebsd.org References: <202301300254.30U2sm0k061914@dell.no.berklix.net> From: User Ngor In-Reply-To: <202301300254.30U2sm0k061914@dell.no.berklix.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.930]; DMARC_POLICY_ALLOW(-0.50)[antonovs.family,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[antonovs.family:s=20200215]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[antonovs.family:+]; ASN(0.00)[asn:14618, ipnet:100.24.0.0/13, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4P4y4t6MB7z3Gl2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N 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