[lotsoflumens]

This practice is seriously bad.

It means that one group of developers is busy improving and fixing packages, and another different group is cherry-picking commits in order to maintain the illusion of stability (as mentioned above).

That second group has to duplicate all the testing work done by the first group, and additionally ensure that there are no new problems introduced.

It's very vulnerable to human error and adds a lot of unnecessary work.

[0x0]

It's better to have a competent "second group" do the backport job rather than every single user of a distro having their rug pulled out under them every time they patch. New versions of software can quickly break your environment. For example, https://gitlab.com/gitlab-org/gitlab-ce/issues/36028 . If you have to re-test every script and web service to ensure compatibility with the daily churn of vulnerability fixes you would get nothing done and you could almost never be sure your service is stable.

[lotsoflumens]

I agree, this is a problem, but it's not being solved by this practice.

The example you gave is specifically about a client application of git that wasn't updated to work with the current version of git - probably because of some twisted logic that they didn't have to worry about it until some future date.

[0x0]

It's an example of how things break if you upgrade to new versions of software. If you avoid going to new versions of software, and instead just backport the essential security fixes, there will be much fewer surprises like this.

Imagine you had a daily backup script that uses git to commit and push to a remote server perhaps managed by someone else. You then upgrade to the latest and greatest version of git to try to patch this vulnerability, and surprise, your backup script fails! Hope you weren't planning on spending the rest of the day getting the guys running the git server to implement a workaround, who might have already left for the weekend, leaving you with no backups or having to manually try to fix your git to work with that server again.

[lotsoflumens]

Well then, I guess with that line of reasoning we should just turn off the computers and go live in the woods. There's obviously too much risk in doing anything.

[0x0]

That's up to you. I find the current system of stable releases to work just right.

[boot13]

Yeah, well, that's just, like, your opinion, man.

I see it differently. Where do new bugs and vulnerabilities come from? When the main developers add features or make changes to existing features that go beyond fixing bugs.

From the point of view of many server administrators, using the latest versions of everything is inherently risky. What they want to use is a stable, solid version that has all the latest security fixes.

It's unlikely that these opposing viewpoints will ever be reconciled.

[lotsoflumens]

It's important for package developers to be aware of other software that depends on their interfaces or functionality.

Some cases will slip through sometimes, but over a couple of releases these should be gone.

>> Where do new bugs and vulnerabilities come from? When the main developers add features or make changes to existing features that go beyond fixing bugs.

Do you have stats for that?

Semantic versioning was supposed to be the fix for that, but as Rich Hickey has pointed out, that is also broken.

Everyone is their own server admin these days. We all want "a stable, solid version that has all the latest security fixes" but it's difficult accept that that might be impossible.

[boot13]

No stats needed. Just go through the bug list for any software. How many of the bugs were introduced by the people who maintain stable packages?

[mcny]

I agree with this sentiment a lot of the time but consider this:

https://bugs.kde.org/show_bug.cgi?id=382911

it is a duplicate of

https://bugs.kde.org/show_bug.cgi?id=378854

which is fixed by https://cgit.kde.org/konversation.git/commit/?id=783dc0f595e...

but upstream for some reason does not think this is important enough to tag and bag into a release.

as much hate as Fedora gets, rdieter has taken the time to backport the changes that we need in Fedora.

https://bodhi.fedoraproject.org/updates/FEDORA-2017-9c3e2138...

Ideally, we'd rather see upstream release this fix but we've all read https://news.ycombinator.com/item?id=14051106 and I don't want to be too impatient with software that upstream has graciously provided for free (in both senses of the word!)

I guess my point is backporting might make sense if there are small changes we can make to enhance release. However, I agree that there is too much duplication of effort going on.

[lotsoflumens]

I've seen that bug!

And, I'm not too surprised, KDE has a broken development and maintenance process. I'm sure they think they're doing a great job - but that's because they don't even see or receive most bug reports.

[mcny]

> And, I'm not too surprised, KDE has a broken development and maintenance process. I'm sure they think they're doing a great job - but that's because they don't even see or receive most bug reports.

KDE actually fixed the bug but it hasn't gone to a tagged release after two months. Maybe they think this small change doesn't warrant a release? I asked if KDE neon can pick it up but they (understandably) seem to see this as feature creep. KDE applications means something different for the neon folks (only the things they ship with neon from what I understand).

I agree. I have no doubt we are all trying to do our best. =)

[rlpb]

You're welcome to use Debian testing, or the development release of Ubuntu. Both update packages as they are released from upstream developers.

[lotsoflumens]

Thanks, but that means I'm doing the testing. I wish I could do that - maybe someday.

[rlpb]

I don't follow. What do you want exactly? The newest stuff pushed straight to users, or not?