Hacker News new | ask | show | jobs
by Touche 3772 days ago
> On the contrary, Debian having a longer release cycle (about every two years), release cycles don't align.

Then change your release cycle. Seriously, it's not that hard. Say that browsers are different and get released frequently. Create a firefox-lts package that is updated at the beginning of your Debian release cycle -- and never again. Let the firefox package be the firefox package, updated as frequently as upstream wants.

6 comments

This is already kind of the case. Debian stable tracks the Firefox ESR releases, updating when a new one comes out. If you want the Firefox frequent releases, you get them with backports from the Debian Mozilla team (out of the main archive).

(For the more adventurous desktop users, they can also use Debian unstable for the frequent releases. Unstable isn't unstable in terms of your machine falling over. Rather, there is a lot of package churn, and you need to use something like "sudo aptitude upgrade --visual-preview" when upgrading to ensure that you don't try to upgrade something in the middle of a big package transition before everything is finished and ready in the package repo.)

If you don't like the 2 year release cycle, use Ubuntu, which is Debian-based. Debian maintains such long release cycles because the tolerance for bugs and incompatibilities are smaller than other linux distros. For long-lived applications or applications that have long planning periods Debian is ideal. NASA uses Debian, because their projects are measured in years, have low tolerances for bugs, and are developed to last 5+ years. Simply put, Debian's release model is for a different use-case than your typical web development project
It's really very nice to just throw Ubuntu 14.04 on everything and not worry about it. I can use my machines for doing work and not have to waste a lot of time dealing with whatever the latest churn is.
Debian has both: I use Stable on my servers and Unstable/Sid (which is a rolling-release distro) on my laptop.
There is also Debian testing which is more polished than Sid, but is also semi-rolling.
What does this have to do with Firefox? Is NASA writing rovers as Web apps? If not what does it matter which version of Firefox is installed?
User experience stability is often a real problem in the corporate or institutional world. Keeping a maximally stable version of Firefox will help corporate users a lot - it's not even necessarily about stability as much as it's about user retraining, in-house extensions, etc.
For most companies what version of firefox probably doesn't matter. However, there are tons of legacy desktop apps in government, call centers etc where installing a new version of firefox will break the application. Hell, the callcenter my company uses an app that will only work with certain versions of ie. The company that made the app went out of business years ago and the only thing the call center has is a binary they install on all desktops.
Literally right below that it says: "To address this packaging issue, once a ESR cycle is over, Debian has been accepting uploads of new ESR releases in the stable release."

As in, they accept and release new versions from upstream instead of maintaining their own fork with backports.

But most users don't want the ESR version, they want the latest non-ESR version, yes, you can go and get it from mozilla but some users find this inconvenient.
Then they can get it from outside the stable branch. Testing and unstable both have a Iceweasel 44, and there is the mozilla repository at http://mozilla.debian.net/ just for mozilla software.

Debian stable is "conservative and with as few changes as possible", so the ESRs are the obvious choice for it.

Debian implements the comical definition of Bureaucracy really well. Missing the forest for the trees and thinking that every single piece of software is built and released the same way.

For a Linux distro that has been around so long, it's mind boggling they still don't understand that. Wine used to have the same problem - Wine's cycle had the Chrome-like cycle before Chrome even existed. Release every 2 weeks like clockwork. Releases are not any more or less stable than the previous one, but they implement more functionality and a newer release will almost always be better than an older one. Wine's "Stable" releases are meaningless, other than "We spend a month working on bugfixes/regression instead of features before a stable release".

I think this is a misunderstanding of the goals of Debian Stable.

The purpose is not to get a stable release of each upstream project and build a release from those. The goal is to get any release of each upstream project, test it for a few months to ensure there are no show-stopping bugs and to document the known ones, and then freeze it.

The goal is not to ensure lack of bugs, it's to ensure stability, that is, that no new bugs appear or existing behaviours change.

The goal is to allow the sysadmin to configure the system, test it - working around existing bugs - and leave it running, being reasonably sure that stuff won't randomly break until he upgrades the major version, while remaining secure.

The problem then is when this trickles down to projects like Ubuntu. For years, Ubuntu (the desktop distro) had Wine 1.0 as its only version of Wine, when there were something like 40 new development releases of it already available. This caused hundreds upon hundreds of bug reports and user frustrations for no good reason - issues were already fixed in most recent versions of Wine.

I used to do triaging for Wine and I can't tell you how depressing that was, the amount of time wasted by these distro policies.

Ubuntu isn't based on debian stable so I'm confused as to why you debian's stable release cycle would have anything to do with ubuntu.
I'm pretty sure scrollaway was describing the stable release philosophy as trickling down to Ubuntu, not the actual packages.
> Release every 2 weeks like clockwork.

Which means exciting new regressions every two weeks! When I used wine it was definitely the case that certain applications(games) worked better with specific wine versions so a continuous release cycle could result in breaking a working application. That's something users of stable are trying to avoid.

If a user wants the latest version of a package you can always install it manually.

I don't disagree with anything you said, but I would like to add that if you become aware of a program that used to work, but no longer does, PLEASE file a bug! We take regressions very seriously[1]. There are often reasons they can't be fixed immediately, but more often we can fix it quickly. But we have to know about it first!

[1] We even have an explicit regression tracker that places blame and shame on whoever broke it! http://source.winehq.org/regressions

I'd love to report more stuff in Wine but isn't there a requirement to be running the latest/dev branch? This is tricky to do in Debian (because I prefer to build debs of whatever and then install those).
You will be asked to test it in the latest release, yes, but perhaps someone else can test it for you, or at least get developer eyes on the issue. In any case, it's unlikely to be just closed invalid without any consideration. We would rather know about it than not.
Parent is actually wrong - Wine releases with the Gnome cycle, where even releases are stable and odd ones are unstable. Debian should technically be shipping both versions according to upstream release cadences - people who want stable use 1.8 right now, and people who want latest features use 1.9.
In what way am I wrong? Wine releases are in fact every two weeks with a stable release once in a while. How is it relevant that stable are even and unstable are odd?
Because Wine (and Gnome) maintain them in parallel. With Chrome you have the one release version that gets constantly updated every two weeks, but unlike Firefox's ESR / Linux's LTS kernels Google doesn't want to maintain an "LTS" version of Chrome.

Yes, its semantics whether you just pin arbitrary releases and call them LTS vs having dedicated versioning schema to support it, but you called it a Chrome like cycle, when its just a more general constant iteration with occasional LTS cycle. Not many products actually use the full blown constant iteration for everyone model Google uses on Chrome.

We still release every 2 weeks on the dot. Next release is on Friday.

And our stable branch is changing to yearly releases! We are going to do a code freeze every Fall and release in late Fall or early Winter. It is also going to receive more regular backports of "safe" improvements, so slow distros like Debian can benefit from important fixes. We've already had a dot-dot stable release this year!

http://source.winehq.org/git/wine.git/shortlog/refs/heads/st...

> For a Linux distro that has been around so long, it's mind boggling they still don't understand that.*

They definitely do understand that - they also offer more packages than any other x86 operating system. It's just that they have a reason for doing it their way. The operating system is meant to provide a stable base, and the user can then select particular software for more frequent upgrades by adding their own target repositories. Or using make.

Debian is one of the two major linux distros that other distros source from. It's a bit weird to suggest that they don't really get how software is developed.

It's a bit sad to see "real" distributions have shrunk to 2. In a way, you can say that's more of a case of these growing while everyone else did not (see: Slackware), and that it's a net positive in terms of consistency, but it might also indicate a retreat from experimental approaches. "Different" distributions like Gentoo failed to capitalize on early momentum, and there is now a general expectation that all * nix systems should look like RH or Debian.
Surprisingly, Chromium is always up to date on the Debian stable release. Why can't they do the same for Iceweasel/Firefox? keep the ESR version and a version that matches upstream latest releases, but there's probably something I'm missing here.
They do the same for Iceweasel: stable gets updated to the ESR x release around when version x.0.1 gets out.
$deity no, then I'd have to rebuild servers every year instead every two/three :/
I have been just doing dup on OpenSUSE for over 6 years without a single issue. :) I am getting rusty on rebuilding server skills.

Debian's update system does drive me nuts, but I have never run a Debian server for longer then 6 months.

Considering the last distro upgrade had Apache going from 2.2 to 2.4, which introduced considerable changes to the config file format, "upgrading the servers" is not something that can be done in _all_ cases.
But that is an issue with Apache and not really a Distro issue. I'm thinking I didn't have to change anything on my Apache config since mine is very vanilla.

So if you have a vanilla config on Apache it still works.