Date: Sun, 5 Feb 2023 11:36:21 -0700 From: Warner Losh <imp@bsdimp.com> To: User Ngor <ihor@antonovs.family> Cc: freebsd-current@freebsd.org Subject: Re: Tooling Integration and Developer Experience Message-ID: <CANCZdfr8i=E-hCvoEG0vikKSO=Y%2BC5hAiT3DoY=PXX7dfa7BLQ@mail.gmail.com> In-Reply-To: <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family> References: <202301300254.30U2sm0k061914@dell.no.berklix.net> <97020cad-f913-2985-2093-e4c23bf671e3@antonovs.family>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ihor@antonovs.family> 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 <div dir=3D"ltr"><div dir=3D"ltr"><div>Greetings,</div><div><br></div><div>= I've created <a href=3D"https://reviews.freebsd.org/D38382">https://rev= iews.freebsd.org/D38382</a> to encourage more people to submit pull request= s for simple fixes.</div><div><br></div><div>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</div><div>has all the normal 'curation' done: author na= me is set right, logically broken down into individual commits (where</div>= <div>more than one is justified), all the 'fixup' commits are squas= hed back, and the change is rebased forward</div><div>with force pushes whe= n there's changes needed (not merged forward).</div><div><br></div><div= >My goal is to provide resolution for all pull requests within a month or t= hree. Resolution might be "this is</div><div>too complex, break it dow= n" or "This needs to be discussed elsewhere" or "This c= hange is just wrong</div><div>and won't be applied in its current form&= quot;, however. This process is supposed to be a quick one for easy</div><d= iv>patches. And if it isn't going to be quick, the patches will be redi= rected elsewhere or the pull request</div><div>closed.<br></div><div><br></= div><div>This is a bit of an extension of an experiment with github pull re= quests I started a while ago and had to</div><div>walk away from for reason= s previously discussed. And there are times that people will want to use pu= ll</div><div>requests to do code review because for the code changing, it&#= 39;s better. Nothing precludes that, so long as</div><div>progress is made = and change land or are abandoned in a timely manner.</div><div><br></div><d= iv>Anyway, I have a doc review to update our docs on this, plus will try to= put this into the github templates</div><div>(though I'd also accept t= hat from others that know it off the top of their head).</div><div><br></di= v><div><a href=3D"https://reviews.freebsd.org/D38382">https://reviews.freeb= sd.org/D38382</a></div><div><br></div><div>Think of this as a way to try to= 'fast path' all the no-brainer changes.<br></div><div><br></div><d= iv>Warner<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Sun, Jan 29, 2023 at 10:52 PM User Ngor <ihor@anto= novs.family> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex">On 1/30/23 02:54, Julian H. Stacey wrote:<br> =C2=A0> Jamie Landeg-Jones wrote:<br> =C2=A0>> <a href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= =3D261657" rel=3D"noreferrer" target=3D"_blank">https://bugs.freebsd.org/bu= gzilla/show_bug.cgi?id=3D261657</a> is a <br> trivial fix<br> =C2=A0>> to an admittedly trivial issue, but it's soon going to h= it one year old,<br> =C2=A0>> and has not had any feedback. Not even "this is rubbish= . close ticket"<br> =C2=A0>><br> =C2=A0>> | jamie@catwalk:~ % stat 'so good they named it twice= 9;<br> =C2=A0>> | stat: so good they named it twice: stat: No such file or d= irectory<br> =C2=A0>><br> =C2=A0>> As such, it's the oldest of my patches to be completely = ignored, but <br> then,<br> =C2=A0>> most of my fixes I haven't even submitted, because, what= 's the point?<br> =C2=A0>> I've instead spent time writing something so the patches= are <br> automatically<br> =C2=A0>> aplied to my src tree, and distributed to all my servers.<br= > <br> Forked from: 1 year src-patch anniversary.<br> <br> I feel Jamie's pain,=C2=A0 this kind of experience can be very discoura= ging <br> to any<br> contributor without commit bit.<br> <br> All developers like quick feedback loops. Nobody wants to wait a year. I <b= r> think<br> FreeBSD project looses a lot of potential contributors due to issues of thi= s<br> kind. I don't believe there is any ill intent, there is no elite cast o= f <br> grumpy<br> commit-bit holders who only work on what they are interested in, <br> ignoring the<br> project as a whole. Far from it.<br> <br> But I do hope that the situation can be improved and I want to offer my <br= > view and opinion.<br> <br> The Problem<br> -----------<br> <br> I do believe that the source of all problems is lack of integration in <br> tooling<br> and communication. Let me elaborate: FreeBSD project has a lot of tools, bu= t<br> the tools are not well integrated together:<br> <br> - There are too many places where a patch can be posted: phabricator, <br> github,<br> =C2=A0=C2=A0 bugzilla, mailing list.<br> <br> - There are too many places to have a conversation: mailing lists, <br> phabricator<br> =C2=A0=C2=A0 reviews, bugzilla comments, github issues and PRs, forum, mult= iple IRC<br> =C2=A0=C2=A0 channels spanning multiple IRC servers, etc.<br> <br> - A posted patch is cat in the bag, there is no pre-commit CI to do some <b= r> basic<br> =C2=A0=C2=A0 sanity-checking, commit-bit holders need to do a lot of work t= o <br> verify the commit<br> =C2=A0=C2=A0 (run CI on it)<br> <br> - Tools are not integrated. There is no information flow between them, no<b= r> =C2=A0=C2=A0 effective cross-referencing, lookup or discover, etc.<br> <br> =C2=A0=C2=A0 - Bugs in Bugzilla are not visible in Phabricator.<br> =C2=A0=C2=A0 - Commits in Phabricator do not resolve bugs in Bugzilla<br> =C2=A0=C2=A0 - Jenkins CI/CD and Phabricator don't know about each othe= r.<br> <br> ... there are probably more examples, but this is enough to draw a few <br> conclusions:<br> <br> <br> 1. Information is fragmented and is easily lost or forgotten.<br> 2. It takes manual human effort to update information in multiple systems.<= br> 3. Human attention (developers, contributors, etc.) to different systems <b= r> is spread<br> =C2=A0=C2=A0=C2=A0 unequally.<br> <br> This leads to poor developer experience, regardless of commit-bit <br> status. A patch posted<br> in bugzilla went unnoticed for a year until frustrated and desperate <br> contributor started<br> complaining about it in the mailing list, and was committed hours later.<br= > <br> The is also a lack of designated maintainers (I am drawing the analogy from= <br> Linux kernel) A role who's job is to integrate: collect all patches, <b= r> feedback,<br> reports about a specific area (kernel subsystem, userland tool or <br> whatnot), and<br> update/curate the knowledge and communication around this area.<br> <br> In my 15+ year career in IT I've seen multiple projects fail due to<br> communication and integration issues. Without concentrated effort and stron= g<br> leadership these problems rarely go away on their own.<br> <br> Proposed Solutions<br> ------------------<br> In the order of implementation:<br> <br> 1. Tooling integration:<br> <br> =C2=A0=C2=A0=C2=A0 This can be as easy as moving everything into Phabricato= r.<br> =C2=A0=C2=A0=C2=A0 Phabricator, apart from features that we already use, ha= s support <br> for CI/CD,<br> =C2=A0=C2=A0=C2=A0 bug reports, wiki, project planning and milestones, chat= , etc.<br> <br> =C2=A0=C2=A0=C2=A0 Alternative platforms can be used as well: GitLab, Sourc= eHut<br> <br> =C2=A0=C2=A0=C2=A0 The main idea: to prevent information fragmentation and = improve<br> =C2=A0=C2=A0=C2=A0 discoverability, cross-referencing abilities, search, et= c.<br> <br> =C2=A0=C2=A0=C2=A0 The challenge: is inertia and migration of existing info= rmation out<br> =C2=A0=C2=A0=C2=A0 of currently used tools.<br> <br> =C2=A0=C2=A0=C2=A0 The sentiment: we don't need more tools, we need few= er tools that work<br> =C2=A0=C2=A0=C2=A0 better together.<br> <br> 2. Growing the community:<br> <br> =C2=A0=C2=A0=C2=A0 Integrated tooling improves productivity and allows focu= sing on <br> quickening<br> =C2=A0=C2=A0=C2=A0 the feedback loop: accepting/rejecting/commenting one-of= f <br> contributions faster.<br> =C2=A0=C2=A0=C2=A0 Regular contributors will be more visible and will get c= ommit-bit <br> faster.<br> =C2=A0=C2=A0=C2=A0 With enough commit-bit holders focused maintainership pr= actice can <br> be started.<br> <br> <br> In the end this is just my opinion, I hope it will spark some conversation.= <br> <br> Thanks for reading this far :)<br> <br> -- <br> Ihor Antonov<br> <br> <br> </blockquote></div></div> --0000000000007a6ccd05f3f83175--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr8i=E-hCvoEG0vikKSO=Y%2BC5hAiT3DoY=PXX7dfa7BLQ>