git: 69c9420a212a - main - news/inn-CURRENT: New port to follow CURRENT snaps

Kevin Bowling kevin.bowling at kev009.com
Sat Jun 12 22:05:09 UTC 2021


On Sat, Jun 12, 2021 at 10:32 AM Alexey Dokuchaev <danfe at freebsd.org> wrote:

> On Sat, Jun 12, 2021 at 10:03:16AM -0700, Kevin Bowling wrote:
> > On Sat, Jun 12, 2021 at 9:52 AM Alexey Dokuchaev wrote:
> > > On Sat, Jun 12, 2021 at 08:53:35AM -0700, Kevin Bowling wrote:
> > > > ...
> > > > There is no technical reason to change the proper names of software,
> > > > it's downright silliness.
> > >
> > > The reason here is mainly organizational, not technical, -- that is,
> > > consistency or, as Mark had very nicely put, trying bring some order
> > > into the chaos which is immanental to the huge collection of software
> > > we have in our ports.  We cannot and should not follow every stupid
> > > upstream naming idea (or any other their stupidity, FWIW).
> >
> > It's not stupid to respect the naming of other people's work.  FreeBSD
> > is FreeBSD, not freebsd, and -CURRENT was -CURRENT not -current.
>
> You're mixing here the proper names and how they map to inherently and
> predominantly lowercase Unix naming tradition, which spans from filenames
> to APIs.
>

To what level do you understand *nix history, cryptic naming had as much to
do with necessity and has little relevance to this conversation about
modern package management which does indeed revolve around proper names.
The file system supports it.  The package manager and {shell, GUI,
web}-completions based on it can aid users in data entry and selection,
that is the right layer to soften data integrity to improve UX.

Outside of FreeBSD, we're reentering an era where people are realizing
machines should operate on properly structured and typed data after a long
period of really bad decisions emphasizing unnecessary and consequential
information erasure at every level.  This includes microprocessors,
programming languages, and data interchange formats.  Ports fall mostly
into the latter, and will eventually need to be evolved or replaced with
something that understands the importance of end to end data fidelity
better.  Weird selectively enforced traditions like this do not help people
learn to reason about computers correctly.


> > If you referred to me as 'kevin' repeatedly I would assume you are lazy
> > and not really care.
>
> Note that both your @gmail.com email and freefall login as all lowercase.
>


> > Software naming is not our choice.
>
> We're not arbitrarily changing names, just brush them so they nicely fit
> together with other packages we offer to our users.
>

The reason I did it that way is I liked how it naturally worked in my port
and it communicated the upstream project naming correctly to users.  So we
are arbitrarily changing something from my intent.  “brush them” is not
technical language that new contributors can follow, let alone could such
weakness in thinking be automated with code.  This is an operating system
engineering project, if you have rules or code to contribute let's do it.

This is my last comment for now and I'm going to go work on src so I don't
have to think about this cringe for a while.. In this thread I've been
casually accused of:
1) Not knowing tradition
2) Not being properly mentored
3) Not working on ports ever
4) Not understanding Unix
5) Some unknown distinction on when to follow GNU/Linux distribution
precedent by someone that is regularly the most vocal opponent in learning
from these other communities

If you ever wonder why FreeBSD is not a mainstream operating system, think
about how we function for a moment.  That's where I'm coming from.  It's
time to get better.


> ./danfe
>


More information about the dev-commits-ports-main mailing list