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
