Fwd: Re: FreeBSD ports community is broken

Forwarding to all original recipients because of being blocked from
the -ports@ list (see below for details) but no maintainer should
*EVER* be blocked from that list

---------- Forwarded message ---------
From: Aryeh Friedman <aryehfriedman@gmail.com>
Date: Sun, Feb 18, 2024 at 5:37 AM
Subject: Re: Re: FreeBSD ports community is broken
To: <ports@freebsd.org>


On Sun, Feb 18, 2024 at 5:16 AM Felix Palmen <zirias@freebsd.org> wrote:
>
> * Tomoaki AOKI <junchoon@dec.sakura.ne.jp> [20240218 17:49]:
> > [a lot about automotive regulations]
>
> That's a nice example how comparisons of entirely different domains
> almost always go completely wrong.

I guess you have never heard of software engineering?

Also the OP is 100% right there is a lot of "brokenish" in the ports
community for example no maintainer should ever be banned from -ports@
but I have been for reasons never explained to me and thus am at a
severe disadvantage when asking for help (like how to switch from yacc
to bison without errors and such).

>
> To start with, cars (and especially individual parts) typically aren't
> subject to consumer customizations, and if they are, it's way outside
> the manufacturer's responsibility.  Here, we were talking about breakage
> that only happened when you customized your port builds. We aren't
> talking about security-relevant breakage either.

Yes they are customized all the time. What do you think "options"?
(same for planes.)

And sadly (speaking as the maintainer of 3 different ports
[devel/aegis, devel/fhist, devel/tailor and when I get time to
unbreaking it and taking maintership devel/cook]) there has to good
customizations that can be done after market without breaking the
ports (for example we use the actual tools above significantly then
how they where designed to be used but due to being the maintainer
still need to maintain the orginal behavior also)


>
> As explained in the PR as well, of course we add (temporary) workarounds
> to *individual* ports when it seems necessary. We certainly don't add
> workarounds to the framework itself unless it's perfectly clear there
> will be no other way. Not even considering yet that just fiddling with
> CFLAGS has the potential to break a lot of other things when done
> globally.

The framework has been broken for a long time. It should not require
prodiere running on a supermassive machine to work (in many cases
portmaster and make install recursion fail where prodiere works).
Also there needs to be a more automated process to review new ports
and maintership changes.   But I think this is more a case of skinny
chefs than purposeful/toxic flame wars.

> All I have left to say is seeing a toxic thread like this is a very
> frustrating experience. So, I'll now move on to something else.

So the solution is to sweep it under the rug til it is too late to be fixed?