FreeBSD ports community is broken

Hi!


I believe that the community engaged in port support has serious problems.
I’m not talking about systematic ignoring reports and patches, on the contrary,
this is a pronounced position of individual (I come out) maintainers.
Instead of solving the problems of the community, they are concerned about the
solution of only their personal problems, and I'm not sure that these are problems
of a technical nature.
There is no more technical discussion in the bugtracker, there are no more references
to Porters Handbook, only a personal opinion as an argument.

I see how FreeBSD Foundation works, and where they directly are responsible for the
result, everything is quite adequate.

In the ports, the situation is the opposite, gangs act there.
(Using the term gang, I do not want to offend the opponent, but only show that +1
repeat the same arguments, sometimes more aggressive. Such behavior scares others
from participation in the discussion.)
If you do not catch your eye, you are doing well. If you do not agree with them, your
problem will never be solved, even when it comes to many others. And you will personally
provoke you into the conflict, repeating repeatedly that no one needs the result of your
work, that this is just Workaround.



Ports Cases

1. devel/pkgconf: unconditionally prioritises base system libraries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273961
Actors: <Charlie Li> vishwin@freebsd.org and <Felix Palmen> zirias@freebsd.org

a) Charlie Li does not want to accept changes that will correct part of the
problems, because personally his problems (Meson) does not solve this.
b) Charlie Li does not want temporary workaround with env var....
c) Charlie Li waits for upstream fix and do not want revert port version
d) Upstream publish fix and no reaction in thread more than 1 month.
e) Bapt come and merge it.

Total:
2023-09-20 - 2023-11-08
1.5 months without the ability to update the ports if you use non default OpenSSL.
1 month after upstream release fix to merge it.
25 users only from those who use the bugtracker, they were waiting for corrections
through the fault of two people who can not even technically justify their decision.



2. graphics/mesa-dri:fix os_same_file_description warning
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276614
Actors: Emmanuel Vadot <manu@freebsd.org> and Gleb Popov <arrowd@FreeBSD.org>

a) FreeBSD Foundation confirm that this should be fixed and implement kcmp() and merge
it to CURRENT

b) Emmanuel Vadot and Gleb Popov - they believe that they know more about Warning than
a person from Mesa who added it and therefore Warning can be ignored.
They did not provide any technical argument.
​
c) Emmanuel Vadot does not care users that use all supported FreeBSD and even DragonflyBSD
so he rufuses to merge os_same_file_description() implementation that uses sysctl() in
bugtracker and same in mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881#note_2247506

tl.,dr: "Changes that correct the problem on all versions of FreeBSD and DragonflyBSD are
not needed because kcmp() was added to FreeBSD Current" - WHAT!?????????????????????????


2.1 graphics/mesa-dri: tries to use devel/elfutils API against base elftoolchain ABI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275443
Current behavior: if devel/elfutils installed - use it.
Made by Emmanuel Vadot.
Apparently personal motives do not allow discussing the patch that uses the system
library, so: "NAK and use poudriere".
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275443#c8




CoC Cases


1. Gleb Popov <arrowd@FreeBSD.org>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276614#c15
Gaslighting / attempt to marginalize oponent (me).
Trying to provoke / trolling.


2. <Charlie Li> vishwin@freebsd.org and <Felix Palmen> zirias@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273961
The constant use of "Workaround" without justification looks like trolling.




PS:
I would like not to arise any problems and Bugtracker was needed only to
add new and updating existing ports.
But since there are problems that affect not only me, I would like to be
corrected promptly, it does not matter how technically the solution is
good or terrible.
If someone does not like the decision or patch, I would like to hear
technically reasonable argument, on the basis of which you can improve the
solution, and not just someone’s opinion that it is Workaround, so there is
nothing to discuss here, and there are many reasons why it is bad, but
we are listing them we will not.
I would also like the patches that “only the author of the patches” are also
taken to be accepted, at least there are many such patches that do not require
effort in support. And if such efforts are needed, you can always create a ticket
and add the author of the patch there. This is called cooperative work.

Another part of cooperative work is the adoption that all people have different
use case and do not need to impose the use of default libraries, default
settings and poudriere.
​
I often hear that there are few resources, few people. People will not increase
so far in the ports the problems are being solved in this way.

I did not want to offend anyone and would like to have a solution to technical
problems in the first place.


PPS: I hope the google translate did not spoil the translation very much.