Is there a story of someone actually getting sucked into doing, say, Debian maintenance within the past five years?

I mean, they have a command line program to report a bug. That and their monstrously complicated packaging apparatus would make me think someone at Debian considered the sucking-in of people to be unethical and thus designed their maintenance polices to prevent it.

> monstrously complicated packaging apparatus

Huh?

.debs are gzip'd tar file with predictable top-level folders and some manifest files. An APT server can be as simple as an FTP site, again with a predictable hierarchy and some manifest files.

Keysigning gets a bit messy but it is still relatively simple.

You can set up your own private package repository in minutes using nothing more than ftpd, gpg, mkdir, and vim.

The documentation is clear, comprehensive, and relatively easy to read.

How is this "monstrously complicated"?

Try to build deb package according to packaging guidelines.

If you are new to debian packaging, make a reservation in your calendar for several evenings, just to figure out what exactly you have to read through.

Did that. Ran an internal APT server for years. Was a fantastic system for doing remote installs on field installations.

Like, you create a folder structure that mimics the final installation inside one of the two toplevel deb folders. The other folder had a manifest or two. Worked easy, and did not take long to figure out

https://blog.knoldus.com/create-a-debian-package-using-dpkg-...

Creating a deb is really easy

I have a script which does various things with git to get a copy of the latest code, tag it, then runs something like

fakeroot dpkg-deb --build ./$packageName/src $packageName.deb

In that src file are things like "usr/whatver", "opt/whatever", "etc/whatever" and "DEBIAN"

In DEBIAN is a really simply control file and sometimes some scripts to do things on install.

Getting a package approved by the debian maintainers is an issue if you don't follow the guidelines (and lintian will help) - just like getting a package approved by the redhat maintainers, but to make your own deb is barely harder than creating a tarball.

> Creating a deb is really easy

That's why I qualified it "according to packaging guidelines".

And I don't want to comply with packaging guidelines because I want to get it into the upstream repo; no, I want it compliant so it is not broken at upgrade time and I don't want to have to solve several problems at once at the most inconvenient time.

With rpm it is both easy and piecemeal - you don't have to have the entire knowledge in your head upright, you can improve it continuosly. You start with spec file and rpmbuild, then find out about rpmlint, then you will find out about mock (so you can build package for Fedora-any version and CentOS-anyversion from any distribution, including Ubuntu or Debian, inside chroot or container) to koji (full blown distro-scale build system).

There's a difference between software evolving and drama. I'm trying to remember an upgrade to Ubuntu or Debian that led to as much manual intervention as the latest update to MacOS or Windows 10.

It's easy to avoid, too.

I haven't had to deal with any drama using Debian or the BSDs, personally speaking. Which I have been since 2000 or so.

Theo from OpenBSD is known to cause controversy, and drama. Its how OpenBSD was born.

That is the best example I can come up with. I do remember Debian libc being broken, as well as the cryptography, but I would not say that was drama.

Controversy is not drama.

The only real time I can think of where they caused any impact to the end users would probably be when they changed up a bunch of software because of licensing issues -around 2001 or so. That also led to them writing or re-writing a lot of software and gave us pf, too. So I'd call it a net gain, personally speaking.

On the linux front -libc6 and the elf change-over caused a lot of breakage; like you said -I'm not sure if I would call that "drama" or not.

Perhaps the difficulty here is that different people are using the same words to mean different things? I would have said that drama and controversy in this case were nearly synonyms, but it sounds like you're using drama to talk about instability in the product instead?

Controversy is a less emotionally loaded term for the same thing (drama/dramatic, toxicity/toxic, harmful/harming). Because of that, it receives more credit in a logic argument.

You are on about direct user impact, where a project discontinuing is perhaps an ultimate one (EOL being moved 8 years in advance is almost that).

Regarding OpenBSD, that isn't the only occurrence. You can grep mailing list archives for some keywords. Look at how people like Daniel Hartmeier, Niels Provos, and Wim Vandeputte got treated. Sure, it did not cause OpenBSD to collapse but I would say it was controversy.

Never seen any drama in the freebsd camp. It’s utterly boring. Which is how I like it.

Huh!? There was some amazing drama here, during the first ports of the early 90s.

https://www.unixmen.com/freebsd-vs-openbsd/

and then the lawsuits:

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/explain...

https://klarasystems.com/articles/history-of-freebsd-part-2-...

Approximately 30 years ago.

Mandatory must-care-about drama since then?

No, not really.

There’s always some drama. Maybe not of the must-care-about but there’s always something.

The ASLR patch comes to mind, as does the KSE / libthr thing.

Equally there have been some very grown up moments. The Matt Dillon / DragonflyBSD fork comes to mind.

There was the... I'm going to call it the no-hugs-coc drama a few years ago (https://www.theregister.com/2018/02/21/freebsd_code_of_condu...). Not exactly earth-shattering, but I think that counts as drama.

Is that no hug thing still in place?

I believe they replaced that coc with a new one since then so I believe it's no longer an issue

You must have missed the FreeBSD code of conduct change 2 years ago and all of the port maintainers who left as a result. I’m not even a FreeBSD user but heard about it.

hug