Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintainers Matter: The case against upstream packaging

kmkeen.com

Post reply on HN
Print view View original

11–20 of 96 posts

Re: Maintainers Matter: The case against upstream packaging

#11

Post by guardiangod »

Preface:

1. I use Arch Linux for my desktop and I like it.

2. I hate docker's repository systems (and other upstream packaging)

But this article writer sure is putting the maintainers on a pedestal.

More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support overhead. Non-bugs are caught and filtered out. Low-quality bugs reported to the distribution's tracker often becomes a good bug when the maintainer reports it upstream.

...

Maintainers also shield users from developers, offering a layer of quality control...choosing a subset of the (subjectively) best software FOSS has to offer. Maintainers will disable features that they feel act in bad faith. Maintainers' greatest power is the ability to outright say "This is not good enough for our users"

Really? Then what about this poor sap who had the misfortune of releasing one buggy minor version, and is now forced to support that for the next 5 years even though the bug was fixed in the next version?

https://news.ycombinator.com/item?id=11452432

The maintainers actively tried to sabotage his attempts to tell people to upgrade to a new version in the name of 'consistency.'

Sure, consistency is great, but only if we (the maintainers) don't have to do any work (such as backporting). We offload all the supports to the developer and have him do support work for us. Then when he complains we will call him a whiner and laugh him off...

Re: Maintainers Matter: The case against upstream packaging

#12

Post by drewcrawford »

I feel like this article is sort of attacking a straw man.

> The promise: Sandboxing makes you immune to bad ISVs. The reality: It protects you from some things and not others.

Well yeah, but the same could be said of maintainers. Maintainers let things through all the time, and sometimes they cause problems (hello, Debian weak keys).

The reality is a bit complicated, and it boils down to something boring like: if the maintainers are better than upstream, maintainers are good, and if they are worse than upstream, then they are bad. But that is both tautological and vacuous, so it is not especially useful insight.

The real insight is this: there just aren't enough maintainers to go around. Debian has 1500 contributors and 57,000 packages, which is 38x as many packages as people. Now maintainers have a lot of tooling to make that more tractable, and upstream developers have their time split between multiple packages too, and some packages are important enough to get the attention of several maintainers fulltime. But do we really believe 1/38th of a person is judiciously considering how to overrule upstream's decisions, attentively investigating user bug reports, and so on?

More likely, the maintainers do not even claim to be doing that, because they have not packaged the software at all. I use lots of unpackaged software; until recently nobody was packaging Chromium for example. Java packaging is really unreliable. And so on.

Ultimately, Ubuntu Snap exists because there is a lot of unpackaged software, and a lot of software packaged poorly. It would be nice if we could wave a magic wand and get 38x more maintainers, but we cannot.

Re: Maintainers Matter: The case against upstream packaging

#13

Post by tremon »

guardiangod wrote: post #11

Preface: 1. I use Arch Linux for my desktop and I like it. 2. I hate docker's repository systems (and other upstream packaging) But this article writer sure is putting the maintainers on a pedestal. More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support ov…

The maintainers actively tried to sabotage his attempts to tell people to upgrade

Ah, poor maintainer. Releasing software with a self-destruct timer is not an acceptable way to "tell people to upgrade".

Re: Maintainers Matter: The case against upstream packaging

#14

Post by gkya »

stormbrew wrote: post #5

This seems like an overly optimistic view of the abilities and resources of distribution package maintainers. The reality is that no matter how hard they try, it's almost impossible for them to keep up, and even with a non-LTS Ubuntu release train I still need to use a number of PPAs and other mechanisms of install to get some things I use on a daily basis. And that's with both Canonical and Debian's resources involv…

When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty.

But with bleeding edge, you lose the control over this. It may be worth it for some users, and not for some others. That's a trade-off, and I myself am at the maintained-package-repo+use-only-stable-releases side; thus I use FreeBSD. Debian and Ubuntu mainly provide stable server OSs, so they're on my side too. If you want bleeding edge software, you should migrate to an OS that provides bleeding edge software, tho should know that it's called bleeding edge is called bleeding for a reason. An OS that has to release a version that'll be stable for the coming five years simply cannot provide bleeding edge packages.

Re: Maintainers Matter: The case against upstream packaging

#16

Post by rodgerd »

gkya wrote: post #14
stormbrew wrote: post #5

This seems like an overly optimistic view of the abilities and resources of distribution package maintainers. The reality is that no matter how hard they try, it's almost impossible for them to keep up, and even with a non-LTS Ubuntu release train I still need to use a number of PPAs and other mechanisms of install to get some things I use on a daily basis. And that's with both Canonical and Debian's resources involv…

When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty. But with bleeding edge, you lose the co…

> An OS that has to release a version that'll be stable for the coming five years simply cannot provide bleeding edge packages.

Wanting software more than every five years is hardly "bleeding edge".

Re: Maintainers Matter: The case against upstream packaging

#17

Post by guardiangod »

tremon wrote: post #13
guardiangod wrote: post #11

Preface: 1. I use Arch Linux for my desktop and I like it. 2. I hate docker's repository systems (and other upstream packaging) But this article writer sure is putting the maintainers on a pedestal. More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support ov…

The maintainers actively tried to sabotage his attempts to tell people to upgrade Ah, poor maintainer. Releasing software with a self-destruct timer is not an acceptable way to "tell people to upgrade".

I know, right? It's not like the maintainers can backport the bug fix in the first place, or upgrade 1 version forward.

Re: Maintainers Matter: The case against upstream packaging

#18

Post by kalessin »

While I agree with a lot of this as well, I feel like downstream packaging has a lot of issues.

I'm working on a project (licensed under the GPLv3) and I have decided to be my own maintainer, i.e: building and distributing packaged versions of my project all by myself:

1. my project is young and unknown, I have no choice but to package it myself (I really like AUR by the way);

2. it lets me write and maintain step-by-step documentation;

3. it allows me to enforce a consistent interface for my project across operating systems, I know my project can be used the exact same way on any operating system I have packaged it for;

4. I have had bad experiences with maintainers having no idea what they are doing and completely breaking my software;

5. It allows me to build a full release pipeline including both source and binary releases.

The first point is sort of a big deal, having packages is important to drive adoption, therefore I need to invest my time in that. I'm not gonna wait for some random folks to package it a few years down the road (if that ever happens).

My work is not incompatible with downstream packaging, but I do intend to work closely with (or directly maintain) any downstream package.

I really feel like this is sort of a catch-22.

Re: Maintainers Matter: The case against upstream packaging

#19

Post by insanebits »

guardiangod wrote: post #11

Preface: 1. I use Arch Linux for my desktop and I like it. 2. I hate docker's repository systems (and other upstream packaging) But this article writer sure is putting the maintainers on a pedestal. More fundamentally, the maintainer is the primary line of defence and interaction between users and developers. Maintainers shield developers from uninformed users, allowing the devs to write software with less support ov…

That's one of the reasons I love arch, it has AUR. Don't like packaging, just create your own.

> Really? Then what about this poor sap who had the misfortune of releasing one buggy minor version

Can't you do a minor do a minor version upgrade? Even the stable distros do updates all the time, just nothing major.

Re: Maintainers Matter: The case against upstream packaging

#20

Post by stormbrew »

gkya wrote: post #14
stormbrew wrote: post #5

This seems like an overly optimistic view of the abilities and resources of distribution package maintainers. The reality is that no matter how hard they try, it's almost impossible for them to keep up, and even with a non-LTS Ubuntu release train I still need to use a number of PPAs and other mechanisms of install to get some things I use on a daily basis. And that's with both Canonical and Debian's resources involv…

When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty. But with bleeding edge, you lose the co…

I didn't say I want an entirely bleeding edge system. I said a bleeding edge ubuntu, by which I mean keeping up to date on the non-LTS track (I updated my original post to say that, because I can see where the confusion lies here).

Out of the 2500 or so packages installed on the computer I'm typing this on, I want about 10 of them to be bleeding edge. Maybe 20.

Post reply on HN