From nobody Sun Feb 5 18:36:21 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 4P8ylk1lpwz3khjh for ; Sun, 5 Feb 2023 18:36:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P8ylh5KDHz4GtH for ; Sun, 5 Feb 2023 18:36:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="cuA5u/1u"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62c) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x62c.google.com with SMTP id m2so28455304ejb.8 for ; Sun, 05 Feb 2023 10:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m/cQrQUuCmzPidyjUXehkXu/Mk72PTpfvIr2cZb2VR4=; b=cuA5u/1uBTc2aq27JtRKMXRzpl9JkorLLBtyWkmxPxaoa1prSgT92LrMqFtp75g3Az VmD1GJzVGvO623s0zjocRgjenot0ufBQV+ygPEAwVpcq9T/W3ntV+iyABDbHduSuVdHG MCmgNv0y0ld8f4pkQJwC01lMa1Iex0vcuXSOkCZxF2yV/ibsfwkQ8r4EvO8Dk07qU2Uo u2qo8SJknx8fDDxJB76rq5NFTUJUW+MehNOWJ5XA3gU5VD6rjYU1W8N8BouYWZ6WoWwo XLbTaKj0V9/rznBZpGKeLrq01r5Hn+YOtDE961H84ApkVnVPe2JgOZCcdkI2K3nJ5v0n vkTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m/cQrQUuCmzPidyjUXehkXu/Mk72PTpfvIr2cZb2VR4=; b=VJYFalW8st1wB5ob3FMb7CskCVR0n+4EF2DEeM8Dp2cj1HfzVwaUBfnxILWX2OSVsM uh6aZbizp9/XtLX67GVzjSEw7rlMlP6EB3Q7Aaq2Qkz8iR8IA3+ghpFyI2XmMgHSzxRZ eWV8PoVqVTzHboePDzSd/RNW2rXasvSX+jZZFRgUkKsP9AxxmRsiJToHiEoa3sQ65yQO jkQQvxtKRt70ZrnyqXn1DqkITEbC3/nN3Q9zFHKKwrQQt8BScWTLP9mDtkrzLQDy1LQu Xzl4Zza2dsy2UxtnPf89wmnH7Rc+BlWduBZRzA+3/92bN28Bxb6p0qBsspfq+xYlAC8o /NeA== X-Gm-Message-State: AO0yUKU7glpq/1AQsaRtAHRT/A6lGJCHROxwIiecCLdah4yOoa2HEeyW Xqk35j7lFcNvBo32ozpPGYuXwESwQq315Td8n8GL03+11fF0E9/2 X-Google-Smtp-Source: AK7set+A1ulFL7ZkYE8boeGQXKt8hPomPYUqxdb0YFtgU9TXofj2eQsfnFFtcuhKHS3nSdmA9j2voRA6I0qR3Z5LlNU= X-Received: by 2002:a17:906:d96d:b0:888:c14e:70b6 with SMTP id rp13-20020a170906d96d00b00888c14e70b6mr5257271ejb.306.1675622191093; Sun, 05 Feb 2023 10:36:31 -0800 (PST) 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 References: <202301300254.30U2sm0k061914@dell.no.berklix.net> <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> In-Reply-To: <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> From: Warner Losh Date: Sun, 5 Feb 2023 11:36:21 -0700 Message-ID: Subject: Re: Tooling Integration and Developer Experience To: User Ngor Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000007a6ccd05f3f83175" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4P8ylh5KDHz4GtH X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000007a6ccd05f3f83175 Content-Type: text/plain; charset="UTF-8" Greetings, I've created https://reviews.freebsd.org/D38382 to encourage more people to submit pull requests for simple fixes. A simple fix is one that's brief, easily reviewed in a few minutes, ready to land in the tree (or nearly so) and has all the normal 'curation' done: author name is set right, logically broken down into individual commits (where more than one is justified), all the 'fixup' commits are squashed back, and the change is rebased forward with force pushes when there's changes needed (not merged forward). My goal is to provide resolution for all pull requests within a month or three. Resolution might be "this is too complex, break it down" or "This needs to be discussed elsewhere" or "This change is just wrong and won't be applied in its current form", however. This process is supposed to be a quick one for easy patches. And if it isn't going to be quick, the patches will be redirected elsewhere or the pull request closed. This is a bit of an extension of an experiment with github pull requests I started a while ago and had to walk away from for reasons previously discussed. And there are times that people will want to use pull requests to do code review because for the code changing, it's better. Nothing precludes that, so long as progress is made and change land or are abandoned in a timely manner. Anyway, I have a doc review to update our docs on this, plus will try to put this into the github templates (though I'd also accept that from others that know it off the top of their head). https://reviews.freebsd.org/D38382 Think of this as a way to try to 'fast path' all the no-brainer changes. Warner On Sun, Jan 29, 2023 at 10:52 PM User Ngor wrote: > 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 > > > --0000000000007a6ccd05f3f83175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

= I've created https://rev= iews.freebsd.org/D38382 to encourage more people to submit pull request= s for simple fixes.

A simple fix is one that's= brief, easily reviewed in a few minutes, ready to land in the tree (or nea= rly so) and
has all the normal 'curation' done: author na= me is set right, logically broken down into individual commits (where
=
more than one is justified), all the 'fixup' commits are squas= hed back, and the change is rebased forward
with force pushes whe= n there's changes needed (not merged forward).

My goal is to provide resolution for all pull requests within a month or t= hree. Resolution might be "this is
too complex, break it dow= n" or "This needs to be discussed elsewhere" or "This c= hange is just wrong
and won't be applied in its current form&= quot;, however. This process is supposed to be a quick one for easy
patches. And if it isn't going to be quick, the patches will be redi= rected elsewhere or the pull request
closed.

This is a bit of an extension of an experiment with github pull re= quests I started a while ago and had to
walk away from for reason= s previously discussed. And there are times that people will want to use pu= ll
requests to do code review because for the code changing, it&#= 39;s better. Nothing precludes that, so long as
progress is made = and change land or are abandoned in a timely manner.

Anyway, I have a doc review to update our docs on this, plus will try to= put this into the github templates
(though I'd also accept t= hat from others that know it off the top of their head).


Think of this as a way to try to= 'fast path' all the no-brainer changes.

Warner

On Sun, Jan 29, 2023 at 10:52 PM User Ngor <ihor@anto= novs.family> wrote:
On 1/30/23 02:54, Julian H. Stacey wrote:
=C2=A0> Jamie Landeg-Jones wrote:
=C2=A0>> https://bugs.freebsd.org/bu= gzilla/show_bug.cgi?id=3D261657 is a
trivial fix
=C2=A0>> to an admittedly trivial issue, but it's soon going to h= it one year old,
=C2=A0>> and has not had any feedback. Not even "this is rubbish= . close ticket"
=C2=A0>>
=C2=A0>> | jamie@catwalk:~ % stat 'so good they named it twice= 9;
=C2=A0>> | stat: so good they named it twice: stat: No such file or d= irectory
=C2=A0>>
=C2=A0>> As such, it's the oldest of my patches to be completely = ignored, but
then,
=C2=A0>> most of my fixes I haven't even submitted, because, what= 's the point?
=C2=A0>> I've instead spent time writing something so the patches= are
automatically
=C2=A0>> aplied to my src tree, and distributed to all my servers.
Forked from: 1 year src-patch anniversary.

I feel Jamie's pain,=C2=A0 this kind of experience can be very discoura= ging
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 thi= s
kind. I don't believe there is any ill intent, there is no elite cast o= f
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, bu= t
the tools are not well integrated together:

- There are too many places where a patch can be posted: phabricator,
github,
=C2=A0=C2=A0 bugzilla, mailing list.

- There are too many places to have a conversation: mailing lists,
phabricator
=C2=A0=C2=A0 reviews, bugzilla comments, github issues and PRs, forum, mult= iple IRC
=C2=A0=C2=A0 channels spanning multiple IRC servers, etc.

- A posted patch is cat in the bag, there is no pre-commit CI to do some basic
=C2=A0=C2=A0 sanity-checking, commit-bit holders need to do a lot of work t= o
verify the commit
=C2=A0=C2=A0 (run CI on it)

- Tools are not integrated. There is no information flow between them, no =C2=A0=C2=A0 effective cross-referencing, lookup or discover, etc.

=C2=A0=C2=A0 - Bugs in Bugzilla are not visible in Phabricator.
=C2=A0=C2=A0 - Commits in Phabricator do not resolve bugs in Bugzilla
=C2=A0=C2=A0 - Jenkins CI/CD and Phabricator don't know about each othe= r.

... 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.<= br> 3. Human attention (developers, contributors, etc.) to different systems is spread
=C2=A0=C2=A0=C2=A0 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 stron= g
leadership these problems rarely go away on their own.

Proposed Solutions
------------------
In the order of implementation:

1. Tooling integration:

=C2=A0=C2=A0=C2=A0 This can be as easy as moving everything into Phabricato= r.
=C2=A0=C2=A0=C2=A0 Phabricator, apart from features that we already use, ha= s support
for CI/CD,
=C2=A0=C2=A0=C2=A0 bug reports, wiki, project planning and milestones, chat= , etc.

=C2=A0=C2=A0=C2=A0 Alternative platforms can be used as well: GitLab, Sourc= eHut

=C2=A0=C2=A0=C2=A0 The main idea: to prevent information fragmentation and = improve
=C2=A0=C2=A0=C2=A0 discoverability, cross-referencing abilities, search, et= c.

=C2=A0=C2=A0=C2=A0 The challenge: is inertia and migration of existing info= rmation out
=C2=A0=C2=A0=C2=A0 of currently used tools.

=C2=A0=C2=A0=C2=A0 The sentiment: we don't need more tools, we need few= er tools that work
=C2=A0=C2=A0=C2=A0 better together.

2. Growing the community:

=C2=A0=C2=A0=C2=A0 Integrated tooling improves productivity and allows focu= sing on
quickening
=C2=A0=C2=A0=C2=A0 the feedback loop: accepting/rejecting/commenting one-of= f
contributions faster.
=C2=A0=C2=A0=C2=A0 Regular contributors will be more visible and will get c= ommit-bit
faster.
=C2=A0=C2=A0=C2=A0 With enough commit-bit holders focused maintainership pr= actice 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


--0000000000007a6ccd05f3f83175--