OK, except jwz says there were security fixes, which changes the equation.
Maybe I missed something, but I read this as: jwz wants to run his project as a single release stream, fixing security issues only in that stream, but the Debian maintainer apparently isn’t willing to backport fixes from that stream to Debian stable. In the bug report, the priority seems to be eliminating the popup message because it makes Debian look bad rather than figuring out how to get the security fixes into stable Debian–which really makes Debian look bad.
That doesn’t sound “wrong”, exactly. It sounds like Debian wants jwz to either do extra work to support their release model, or suffer reputational damage from having an old insecure version of his software in the distro.
I know they’re supposed to backport security fixes. I’ve based my whole company on Debian and trust them to do that. Which is why I’m disappointed that people seem to be exclusively annoyed with jwz for putting this helpful last-resort canary in the code rather than annoyed with the maintainer for being asleep at the switch.
I think xscreensaver has no public VCS repository, only release tarballs. This just doesn’t jive with the stable update system Debian wants to run, and I wouldn’t expect someone to honestly try to isolate security fixes from diffs between entire releases in order to backport them.
I don’t know what the policy behind the {release}-updates system is, but considering the upstream constraints and that this is a somewhat security-relevant package, maybe this should join alongside web browsers and be an evergreen package on stable releases, or, with consideration to the maintainer’s position, dropped as something untenable for stable Debian if they can’t get it on that system.
As I said above, it sounds like Debian wants jwz to do extra work to support their release model. If the Debian maintainer doesn’t want to put up with upstream’s dev process, it isn’t upstream’s problem, it’s Debian’s problem. If the maintainer doesn’t want to put in the effort to backport (which in this case would include making diffs) then yes, it should be dropped. Which is exactly what jwz asked for.
For what it’s worth, I have gotten Debian to stop shipping one of my projects. They had Leiningen 1.7 in apt-get, but version 2.x added so many dependencies (in 2013) that the maintainers still haven’t gotten them packaged yet. It didn’t take long for projects in the wild to drop support for 1.x, at which point having the package in Debian caused more problems than it solved.
They were quite willing to remove it from the repositories, but I suppose that situation is quite different because it was a much more obscure tool that no other packages depended upon.
In any case, this particular tantrum is particularly hilarious in light of his complaints about CADT.
… how?
The CADT model is where bugs linger until “we’re rewriting the whole thing anyway”, particularly cases where the same bugs recur in the new iteration – to the effect that bugs get rewritten continuously but never fixed.
What is the hilarious parallel to the situation in which jwz does fix bugs that Debian then won’t ship?
As a Debian user, I wouldn’t like them to do that. I use Debian stable (in some cases, not all) because I like Debian’s model of release management. I understand its pluses and minuses, and use it when it’s what I want. When that’s the case, what I don’t want is random updates coming in from upstream, following whatever release model each separate upstream feels like following. If I wanted a rolling-release distro with the latest versions from upstream, I wouldn’t be using Debian stable!
Fortunately, this being the free-software world, I have a choice. You can use a rolling-release distro; you can use a stable-branch distro; there are many options, of which Debian stable is only one. I don’t like jwz trying to tell me that he should get to decide for me which one I am allowed to use. If he wants that kind of micromanaged control over downstream users, then maybe the free-software world isn’t the right one for him. Branches and forks that let us adapt software to our own needs is one of the advantages of free software, and therefore “don’t branch my software” isn’t a reasonable request in the free-software world.
edit: Also, completely unsurprisingly, jwz is acting like a real asshole in the linked bug report. As usual, he seems to get viscerally angry at the idea that people might disagree with him, and that he might just be wrong. Yes, you’re rich dude, but that doesn’t let you buy your way everywhere.
Debian (because Debians gonna Debian) refuses to ship a newer, bug-fixed version of xscreensaver without going through proper stable-channel internal processes.
Debian stable-channel internal processes are glacial at best, but the maintainer for this package is apparently asleep at the wheel.
Debian is sick of getting bug reports because the program (functioning as designed) is complaining that it is too old.
The current problem is due to either Debian not watching what it merges from upstream (or else it should’ve caught the time bomb) or to Debian being lazy at actually following upstream.
Let’s be honest: if the users are running Debian stable and are getting a message from their screensaver saying “Hey, holy shit, this is an older version of the software!”, they’re getting what they signed up for.
And sure, Grandpa Zawinski is a kinda grumpy. Then again, you know, he’s been doing open source longer than probably anyone who is currently a member of Lobsters, and has shipped some projects (you may have heard of Netscape, XEmacs, xscreensaver, and some other interesting hacks). He’s also dealt, for over twenty years, with all the bullshit of vendors and package maintainers.
In short, he’s seen it all, and the novelty has probably long-since worn off.
One thing I don’t entirely get is why Grandpa Zawinski, master hacker who can’t stand the incompetence of the yunguns who don’t know how to do software right… has had 24 years to debug his screensaver, but still can’t ship a version that is even somewhat solid, enough not to need critical security updates all the goddamn time. Maybe that’s the argument for removing it from Debian stable, that it’s simply too buggy to be released as part of a long-term-support distribution.
(Can’t find a good link, but I seem to recall that this kind of argument has actually been used successfully for Debian packages in the past: packages where the ratio of security problems to package necessity is particularly high get a permanent bug filed against them of high enough severity to keep the package from ever migrating out of “unstable” into an official Debian release. Which would seemingly resolve the dispute in this case.)
More pertinent I think is that there isn’t a public repository. That probably makes it difficult for the Debian maintainer to pick out and backport security-related bugfixes.
He explains his reasons for the update notification clearly in its sourcecode (and quoted again in the blog and issue tracker). Your post is full of entitlement, not jwz’s.
If you create a fork, do it cleanly: Under a new name, with new contact information. Not the way Debian packaging does it.
I don’t feel entitled to him doing anything. He can quit maintaining it if he wants. Or he can maintain it if he wants. I don’t care either way! What he does not have the right to do is tell Debian they aren’t allowed to run a distro that ships stable branches of software, because he wants to follow the “everyone downstream must release shit whenever I want them to” model of release management. How distributions release-manage their software isn’t his decision.
For what it’s worth, I’d have the same view if RMS wrote some giant rant about OpenBSD shipping an old version of gcc and refusing to update it. That’s OpenBSD’s decision, not RMS’s. As a free software author, you have no right to micromanage downstream releases. Not only no legal right to do so, but no ethical right to do so. No right of any kind!
I’m sorry, who in Debian is asking jwz to do anything? Before he stuck his head into the Debian bug report, there was no mention of him doing anything at all.
The people who send bugs reports against old versions that are shipped by debian to him instead of debian’s bug tracking system.
I am constantly getting email from users reporting bugs that have
been fixed for literally years who have no idea that the software
they are running is years out of date. Yes, it would be great if we
lived in the ideal world where people checked that they were running
the latest release before they report a bug, but we don’t
That message was put there at least two years ago, and it doesn’t seem the situation changed.
Also, a comment below says jwz should now do CVE management, if I understood it correctly.
I am constantly getting email from users reporting bugs that have been fixed for literally years who have no idea that the software they are running is years out of date.
who’s asking jwz to do anything?
The users are asking him to answer questions about his software. This takes time. Maybe even a lot of it.
He does have the right to dictate how his software is distributed, because it is his name in the copyright, and it is his contact information people are making use of if stuff isn’t working. Whether this right is legally or only morally enforcable is a different question.
I strongly doubt you have read or understood anything from jwz’s blogpost.
I have read his blogpost. But I don’t find his request reasonable. He’s angry that buggy software he released a while ago doesn’t just instantly disappear from the world on his whim. Updates take a while to percolate downstream, since different people have different release cycles. That’s how things work, not everyone jumps on your command to ship your bugfixes.
He could avoid the problem, though, by shipping software that had fewer bugs in the first place. ;-)
He’s angry that buggy software he released a while ago doesn’t just instantly disappear from the world on his whim.
The problem he has is that users don’t check the version, and assume it to be the latest one. Debian claims it is shipping the “stable” release of Xscreensaver, by redefining the entire vocabulary around software versioning. I don’t think we’re reading the same words.
Updates take a while to percolate downstream, since different people have different release cycles.
It is his project, it is his release cycle. If Debian can’t comply, it has no business shipping his software under his name, with his support email address, with a link to his bugtracker, leading Debian users to send support requests that would be more suitable to file against Debian. But unfortunately Debian’s bugtracker is a piece of shit, so most users will just email the original author, not the maintainer of Debian’s fork.
If Debian can’t comply, it has no business shipping his software under his name
Again, I don’t see this as a reasonable requirement for free software. It is quite common for people to update things at their own pace, which is sometimes close to “never”. Do you also think that OpenBSD has a moral obligation to stop calling the old version of gcc they ship “gcc”, and stop labeling it as software produced by the Free Software Foundation? Or likewise for Apple and the ancient version of bash they ship? Should they be required to rename it appabash or something? Should the FSF put in a timebomb that causes old versions of bash to pop up warnings if Apple doesn’t update it fast enough for RMS’s liking? I don’t think these kinds of purity requirements on downstream really make sense. The FSF can ask people to update, but I think Apple or OpenBSD can also perfectly well say, “yeah, no thanks”. Even if the FSF gets some old bug reports as a result, in my opinion they are not having their moral rights as authors violated because someone else chooses not to ship the latest version of their software. And likewise for jwz and his screensaver.
As far as I know, few end users report bugs in OpenBSD gcc 4.2 to gcc, so the situations aren’t exactly comparable. Fwiw I’ve gone through the source tree and actually deleted a few instances in other programs where people were told to contact ancient email addresses with bugs.
Ultimately, I place a great deal of weight on the author’s wishes. Licenses are just a means of enforcing/expressing them, and we use standardized licenses as a means of convenience because poorly worded licenses are a legal disaster, but if an author expresses a custom wish, we should respect that.
You have not understood anything. It is not about very old releases being publicly available under his name. It is about software distros publishing them as the latest one, and having it as policy that updates take a long time.
Can you point me to Debian claiming that the software released in stable is the latest version of that software? Given that that explicitly conflicts with pretty much all their messaging about how packaging works, I imagine they would appreciate a bug report to fix it.
jwz is experiencing an immediate and obvious consequence of releasing freely-redistributable software: people will freely redistribute it. If he’s regretting that, fine, but throwing a tantrum does nothing to make him look reasonable or get people to take his point seriously.
I would not classify this post as a tantrum. He made a request; it was ignored, perhaps because misunderstood or not taken seriously. He writes a post that he’s serious. Not a tantrum.
As I read the bug thread, I don’t see his request being ignored, but a discussion on what to do about it. Of the Debian developers replying to the thread (scanning for debian.org email addresses), one wants to remove xscreensaver, two want to keep it but reduce how many Debian users might end up with it installed w/o knowing what they’re doing (by changing dependencies so that xfce no longer “suggests” xscreensaver), and one wants to keep it but remove jwz’s contact info from anywhere it appears in user-visible locations, to ensure he doesn’t get bug reports. There’s separately some kind of running flamewar between jwz and other respondents to the thread who aren’t Debian developers, but the Debian developers are studiously ignoring that flamewar.
Can you point me to Debian claiming that the software released in stable is the latest version of that software?
Literally the term “stable”.
No doubt you have documented your entire vocabulary somewhere, but unfortunately most computer users are not keen on reading documentation, much less on learning a new language.
jwz is experiencing an immediate and obvious consequence of releasing freely-redistributable software: people will freely redistribute it.
I don’t think anybody claimed it is illegal for them to do so. But your entire decision-making shouldn’t solely rely on that question. Empathy should be a factor as well.
To me this is a perfectly common expectation with operating systems: they include whatever software version was current at the time of the OS release, and don’t normally update until the next time there’s an OS release. Who has the opposite expectation? This is exactly how it works from other vendors, too. When Apple makes an OSX release, the versions of perl, python, and whatever else they ship are frozen. Apple updates them when they cut a new release, a year or so later. The decision when to update them is made on Apple’s schedule, not upstream’s. If the Perl Foundation cuts a new release, they have no way to push it into the Apple release. Do you think this is a bad arrangement, and they actually should be able to control Apple’s release schedule?
Apple ships popular software projects which normally have the appropriate infrastructure for supporting older versions. Compare this to Debian, which just packages every piece of software under the sun, be it hobby project or not.
Apple doesn’t visibly present the open source software it uses in the UI, and mostly you can only get version and contact information of the included libraries from the command line.
The packaging story for OS X and Debian may be very similar on the surface, but the outcomes are very different: People mostly blame Apple for shipping a broken installation of OS X. Linux users are unfortunately just informed enough to see that their system is made of software by many authors.
According to the the XScreenSaver home page the current release as of today seems to be 5.34 and according to Debian package tracker that release was added into unstable on 2015-10-26 and migrated to testing on 2015-10-31.
Debian stable has 5.30, but just updating XScreenSaver on a distribution with long term support guarantees is usually not done, because it might cause regressions. For security updates Debian has a separate channel, if JWZ is complaining that the old version has security issues, he could publish advisories, for all long-term supported distributions like RHEL, Debian stable, Ubuntu LTS etc to profit from.
After thoroughly reading the Debian bug thread, the problem is a catch 22.
Debian’s release model dictates that packages simply never change. The users also believe that packages also never change. What I personally think is that there should be a model for this kind of thing; if a security update is needed, it should be provided for non-trivial software; or, ship both versions, allow downgrades to the old version, and if the new version is required, allow it. For things like nginx, Apache2, PHP, et al, you don’t want change, as these are critical to servers. However, if you’re running something like XScreenSaver (which wouldn’t be installed on servers as you probably don’t need it), perhaps let it in; especially because 5.34 fixed bugs for the sake of stability.
Debian’s users are seeing stability as unchanging, but the developer sees stability as having the bugs actually fixed. If the developer wants bugs fixed with this model, he either has to convince Debian users to entirely change their mindset on “what is stable and what is not”, or keep pestering the maintainer to just update it. Something like a screensaver doesn’t exactly “change” aside from new screensavers; if you look at the changelog you see that important things haven’t really happened lately until 5.34.
XScreenSaver is critical to most desktop systems for security, and “just using an alternative” would be bad due to linking with larger libs. However, Debian users and the developer’s will clash. The developer wants to fix the package, but the users don’t want to for questionable “stability” purposes, which causes the maintainer to not update it, which causes the developer to pester the maintainer, which causes more drama, which causes the users to not want to update because the developer is being “rude” by messing with Debian (and for questions “stability” purposes), which causes the developer to pester the maintainer, which causes the users to not want to update. Thus continues the death spiral.
What if upstream maintainers did the same as some enterprise software companies do, and slightly modify their license or have some secondary document explicitly stating that support for a release is only available for two years or for the current major or minor and one major or minor prior?
That way a maintainer of software can say, “I’ll take bug reports on the current release and the last minor of the last major version for up to two years after the release of the new major version.”
Almost every free software license completely disclaims support anyway (“THERE IS NO WARRANTY” from section 15 of the GPL, for instance). The author providing user support for their software is conventional, but optional.
OK, except jwz says there were security fixes, which changes the equation.
Maybe I missed something, but I read this as: jwz wants to run his project as a single release stream, fixing security issues only in that stream, but the Debian maintainer apparently isn’t willing to backport fixes from that stream to Debian stable. In the bug report, the priority seems to be eliminating the popup message because it makes Debian look bad rather than figuring out how to get the security fixes into stable Debian–which really makes Debian look bad.
That doesn’t sound “wrong”, exactly. It sounds like Debian wants jwz to either do extra work to support their release model, or suffer reputational damage from having an old insecure version of his software in the distro.
Debian backports security fixes. The maintainer being apparently inactive is a tangential issue for which there is already an open bug.
I know they’re supposed to backport security fixes. I’ve based my whole company on Debian and trust them to do that. Which is why I’m disappointed that people seem to be exclusively annoyed with jwz for putting this helpful last-resort canary in the code rather than annoyed with the maintainer for being asleep at the switch.
I think xscreensaver has no public VCS repository, only release tarballs. This just doesn’t jive with the stable update system Debian wants to run, and I wouldn’t expect someone to honestly try to isolate security fixes from diffs between entire releases in order to backport them.
I don’t know what the policy behind the {release}-updates system is, but considering the upstream constraints and that this is a somewhat security-relevant package, maybe this should join alongside web browsers and be an evergreen package on stable releases, or, with consideration to the maintainer’s position, dropped as something untenable for stable Debian if they can’t get it on that system.
As I said above, it sounds like Debian wants jwz to do extra work to support their release model. If the Debian maintainer doesn’t want to put up with upstream’s dev process, it isn’t upstream’s problem, it’s Debian’s problem. If the maintainer doesn’t want to put in the effort to backport (which in this case would include making diffs) then yes, it should be dropped. Which is exactly what jwz asked for.
They’re not asking for him to do something unique, non-standard or Debian-specific. They’re asking him to follow basic good practice.
That’s… not that old? Especially for a screen saver program. That’s been around since 1992.
If memory serves, in the last year or so, there was at least one bug in the lock dialog that was fixed.
When software has a critical vulnerability that is patched in a newer release, it becomes old instantly.
For what it’s worth, I have gotten Debian to stop shipping one of my projects. They had Leiningen 1.7 in apt-get, but version 2.x added so many dependencies (in 2013) that the maintainers still haven’t gotten them packaged yet. It didn’t take long for projects in the wild to drop support for 1.x, at which point having the package in Debian caused more problems than it solved.
They were quite willing to remove it from the repositories, but I suppose that situation is quite different because it was a much more obscure tool that no other packages depended upon.
This story is not complete without mentioning jwz’s conduct on the relevant Debian bug report.
In any case, this particular tantrum is particularly hilarious in light of his complaints about CADT.
… how?
The CADT model is where bugs linger until “we’re rewriting the whole thing anyway”, particularly cases where the same bugs recur in the new iteration – to the effect that bugs get rewritten continuously but never fixed.
What is the hilarious parallel to the situation in which jwz does fix bugs that Debian then won’t ship?
In the same bug report, it took someone less than 34 hours to compare him to terrorists (n.b.: isn’t it about time to update Godwin’s law?).
As a Debian user, I wouldn’t like them to do that. I use Debian stable (in some cases, not all) because I like Debian’s model of release management. I understand its pluses and minuses, and use it when it’s what I want. When that’s the case, what I don’t want is random updates coming in from upstream, following whatever release model each separate upstream feels like following. If I wanted a rolling-release distro with the latest versions from upstream, I wouldn’t be using Debian stable!
Fortunately, this being the free-software world, I have a choice. You can use a rolling-release distro; you can use a stable-branch distro; there are many options, of which Debian stable is only one. I don’t like jwz trying to tell me that he should get to decide for me which one I am allowed to use. If he wants that kind of micromanaged control over downstream users, then maybe the free-software world isn’t the right one for him. Branches and forks that let us adapt software to our own needs is one of the advantages of free software, and therefore “don’t branch my software” isn’t a reasonable request in the free-software world.
edit: Also, completely unsurprisingly, jwz is acting like a real asshole in the linked bug report. As usual, he seems to get viscerally angry at the idea that people might disagree with him, and that he might just be wrong. Yes, you’re rich dude, but that doesn’t let you buy your way everywhere.
As I understand it:
The current problem is due to either Debian not watching what it merges from upstream (or else it should’ve caught the time bomb) or to Debian being lazy at actually following upstream.
Let’s be honest: if the users are running Debian stable and are getting a message from their screensaver saying “Hey, holy shit, this is an older version of the software!”, they’re getting what they signed up for.
And sure, Grandpa Zawinski is a kinda grumpy. Then again, you know, he’s been doing open source longer than probably anyone who is currently a member of Lobsters, and has shipped some projects (you may have heard of Netscape, XEmacs, xscreensaver, and some other interesting hacks). He’s also dealt, for over twenty years, with all the bullshit of vendors and package maintainers.
In short, he’s seen it all, and the novelty has probably long-since worn off.
One thing I don’t entirely get is why Grandpa Zawinski, master hacker who can’t stand the incompetence of the yunguns who don’t know how to do software right… has had 24 years to debug his screensaver, but still can’t ship a version that is even somewhat solid, enough not to need critical security updates all the goddamn time. Maybe that’s the argument for removing it from Debian stable, that it’s simply too buggy to be released as part of a long-term-support distribution.
(Can’t find a good link, but I seem to recall that this kind of argument has actually been used successfully for Debian packages in the past: packages where the ratio of security problems to package necessity is particularly high get a permanent bug filed against them of high enough severity to keep the package from ever migrating out of “unstable” into an official Debian release. Which would seemingly resolve the dispute in this case.)
The changelog suggests security fixes aren’t exactly happening all the goddamn time.
More pertinent I think is that there isn’t a public repository. That probably makes it difficult for the Debian maintainer to pick out and backport security-related bugfixes.
I agree that it’s not a great release model. I don’t like it either. Choosing to exclude it from the distro is entirely reasonable imo.
He explains his reasons for the update notification clearly in its sourcecode (and quoted again in the blog and issue tracker). Your post is full of entitlement, not jwz’s.
If you create a fork, do it cleanly: Under a new name, with new contact information. Not the way Debian packaging does it.
I don’t feel entitled to him doing anything. He can quit maintaining it if he wants. Or he can maintain it if he wants. I don’t care either way! What he does not have the right to do is tell Debian they aren’t allowed to run a distro that ships stable branches of software, because he wants to follow the “everyone downstream must release shit whenever I want them to” model of release management. How distributions release-manage their software isn’t his decision.
For what it’s worth, I’d have the same view if RMS wrote some giant rant about OpenBSD shipping an old version of gcc and refusing to update it. That’s OpenBSD’s decision, not RMS’s. As a free software author, you have no right to micromanage downstream releases. Not only no legal right to do so, but no ethical right to do so. No right of any kind!
You also have no obligation to micromanage support of them.
I’m sorry, who in Debian is asking jwz to do anything? Before he stuck his head into the Debian bug report, there was no mention of him doing anything at all.
The people who send bugs reports against old versions that are shipped by debian to him instead of debian’s bug tracking system.
That message was put there at least two years ago, and it doesn’t seem the situation changed.
Also, a comment below says jwz should now do CVE management, if I understood it correctly.
I don’t want to use software to secure my computer if the authors don’t want to do CVE management.
Quoting straight from jwz:
The users are asking him to answer questions about his software. This takes time. Maybe even a lot of it.
I’m sorry, I meant “who in Debian”, not “who in general”. I presumed that was clear from context.
Good point! They’re not even asking.
He does have the right to dictate how his software is distributed, because it is his name in the copyright, and it is his contact information people are making use of if stuff isn’t working. Whether this right is legally or only morally enforcable is a different question.
I strongly doubt you have read or understood anything from jwz’s blogpost.
I have read his blogpost. But I don’t find his request reasonable. He’s angry that buggy software he released a while ago doesn’t just instantly disappear from the world on his whim. Updates take a while to percolate downstream, since different people have different release cycles. That’s how things work, not everyone jumps on your command to ship your bugfixes.
He could avoid the problem, though, by shipping software that had fewer bugs in the first place. ;-)
The problem he has is that users don’t check the version, and assume it to be the latest one. Debian claims it is shipping the “stable” release of Xscreensaver, by redefining the entire vocabulary around software versioning. I don’t think we’re reading the same words.
It is his project, it is his release cycle. If Debian can’t comply, it has no business shipping his software under his name, with his support email address, with a link to his bugtracker, leading Debian users to send support requests that would be more suitable to file against Debian. But unfortunately Debian’s bugtracker is a piece of shit, so most users will just email the original author, not the maintainer of Debian’s fork.
Again, I don’t see this as a reasonable requirement for free software. It is quite common for people to update things at their own pace, which is sometimes close to “never”. Do you also think that OpenBSD has a moral obligation to stop calling the old version of gcc they ship “gcc”, and stop labeling it as software produced by the Free Software Foundation? Or likewise for Apple and the ancient version of bash they ship? Should they be required to rename it appabash or something? Should the FSF put in a timebomb that causes old versions of bash to pop up warnings if Apple doesn’t update it fast enough for RMS’s liking? I don’t think these kinds of purity requirements on downstream really make sense. The FSF can ask people to update, but I think Apple or OpenBSD can also perfectly well say, “yeah, no thanks”. Even if the FSF gets some old bug reports as a result, in my opinion they are not having their moral rights as authors violated because someone else chooses not to ship the latest version of their software. And likewise for jwz and his screensaver.
As far as I know, few end users report bugs in OpenBSD gcc 4.2 to gcc, so the situations aren’t exactly comparable. Fwiw I’ve gone through the source tree and actually deleted a few instances in other programs where people were told to contact ancient email addresses with bugs.
Ultimately, I place a great deal of weight on the author’s wishes. Licenses are just a means of enforcing/expressing them, and we use standardized licenses as a means of convenience because poorly worded licenses are a legal disaster, but if an author expresses a custom wish, we should respect that.
He put his name and email address on it. He has no one to blame but himself for it being there.
You have not understood anything. It is not about very old releases being publicly available under his name. It is about software distros publishing them as the latest one, and having it as policy that updates take a long time.
Can you point me to Debian claiming that the software released in stable is the latest version of that software? Given that that explicitly conflicts with pretty much all their messaging about how packaging works, I imagine they would appreciate a bug report to fix it.
jwz is experiencing an immediate and obvious consequence of releasing freely-redistributable software: people will freely redistribute it. If he’s regretting that, fine, but throwing a tantrum does nothing to make him look reasonable or get people to take his point seriously.
I would not classify this post as a tantrum. He made a request; it was ignored, perhaps because misunderstood or not taken seriously. He writes a post that he’s serious. Not a tantrum.
As I read the bug thread, I don’t see his request being ignored, but a discussion on what to do about it. Of the Debian developers replying to the thread (scanning for debian.org email addresses), one wants to remove xscreensaver, two want to keep it but reduce how many Debian users might end up with it installed w/o knowing what they’re doing (by changing dependencies so that xfce no longer “suggests” xscreensaver), and one wants to keep it but remove jwz’s contact info from anywhere it appears in user-visible locations, to ensure he doesn’t get bug reports. There’s separately some kind of running flamewar between jwz and other respondents to the thread who aren’t Debian developers, but the Debian developers are studiously ignoring that flamewar.
Literally the term “stable”.
No doubt you have documented your entire vocabulary somewhere, but unfortunately most computer users are not keen on reading documentation, much less on learning a new language.
I don’t think anybody claimed it is illegal for them to do so. But your entire decision-making shouldn’t solely rely on that question. Empathy should be a factor as well.
To me this is a perfectly common expectation with operating systems: they include whatever software version was current at the time of the OS release, and don’t normally update until the next time there’s an OS release. Who has the opposite expectation? This is exactly how it works from other vendors, too. When Apple makes an OSX release, the versions of perl, python, and whatever else they ship are frozen. Apple updates them when they cut a new release, a year or so later. The decision when to update them is made on Apple’s schedule, not upstream’s. If the Perl Foundation cuts a new release, they have no way to push it into the Apple release. Do you think this is a bad arrangement, and they actually should be able to control Apple’s release schedule?
The packaging story for OS X and Debian may be very similar on the surface, but the outcomes are very different: People mostly blame Apple for shipping a broken installation of OS X. Linux users are unfortunately just informed enough to see that their system is made of software by many authors.
He didn’t tell them they weren’t allowed to - he told them he didn’t want them to, even though he realizes they are allowed to.
Also see this as to why “just using an alternative” (e.g. gnome-screensaver) is bad, and they should just update the package.
According to the the XScreenSaver home page the current release as of today seems to be 5.34 and according to Debian package tracker that release was added into unstable on 2015-10-26 and migrated to testing on 2015-10-31.
Debian stable has 5.30, but just updating XScreenSaver on a distribution with long term support guarantees is usually not done, because it might cause regressions. For security updates Debian has a separate channel, if JWZ is complaining that the old version has security issues, he could publish advisories, for all long-term supported distributions like RHEL, Debian stable, Ubuntu LTS etc to profit from.
After thoroughly reading the Debian bug thread, the problem is a catch 22.
Debian’s release model dictates that packages simply never change. The users also believe that packages also never change. What I personally think is that there should be a model for this kind of thing; if a security update is needed, it should be provided for non-trivial software; or, ship both versions, allow downgrades to the old version, and if the new version is required, allow it. For things like nginx, Apache2, PHP, et al, you don’t want change, as these are critical to servers. However, if you’re running something like XScreenSaver (which wouldn’t be installed on servers as you probably don’t need it), perhaps let it in; especially because 5.34 fixed bugs for the sake of stability.
Debian’s users are seeing stability as unchanging, but the developer sees stability as having the bugs actually fixed. If the developer wants bugs fixed with this model, he either has to convince Debian users to entirely change their mindset on “what is stable and what is not”, or keep pestering the maintainer to just update it. Something like a screensaver doesn’t exactly “change” aside from new screensavers; if you look at the changelog you see that important things haven’t really happened lately until 5.34.
XScreenSaver is critical to most desktop systems for security, and “just using an alternative” would be bad due to linking with larger libs. However, Debian users and the developer’s will clash. The developer wants to fix the package, but the users don’t want to for questionable “stability” purposes, which causes the maintainer to not update it, which causes the developer to pester the maintainer, which causes more drama, which causes the users to not want to update because the developer is being “rude” by messing with Debian (and for questions “stability” purposes), which causes the developer to pester the maintainer, which causes the users to not want to update. Thus continues the death spiral.
What if upstream maintainers did the same as some enterprise software companies do, and slightly modify their license or have some secondary document explicitly stating that support for a release is only available for two years or for the current major or minor and one major or minor prior?
That way a maintainer of software can say, “I’ll take bug reports on the current release and the last minor of the last major version for up to two years after the release of the new major version.”
Almost every free software license completely disclaims support anyway (“THERE IS NO WARRANTY” from section 15 of the GPL, for instance). The author providing user support for their software is conventional, but optional.
if this would be implemented as npm, I can imagine some serious havoc… :-)