4 ms·

jwz here seems to be arguing that distros shouldn't be allowed to freeze his software, even if they do it themselves and maintain the branch themselves. He want

jwz here seems to be arguing that distros shouldn't be allowed to freeze his software, even if they do it themselves and maintain the branch themselves. He wants only current versions of his software shipped, and old versions disabled once they reach a certain age. I don't think this is an entirely reasonable demand, at least for open-source software.

maxerickson 11y ago
More charitably, he thinks the distro choice to freeze something should result in 0 headaches for him. The idea that the freeze should be done without carefully taking responsibility for it is probably a pretty stupid norm, so I can understand the lack of patience.
zanny 11y ago
It should be perfectly reasonable, it is just that within the infrastructure of projects like Debian and RHEL there are no mechanisms for a developer to assume responsibility for their own software. The disconnect of both behavior and authority in pushing new releases vs distributing new releases is a problem, particularly for user facing applications and collections like KDE or VLC. Debian can, and should, freeze their software and provide support for what they package. But the developer should both be able to ask Debian to remove it, and to provide it themselves. But not in the traditional insanely bad and broken Windows "search the Internet for random binaries and use those" method. We have the capability, fairly easily, to provide a community repository that crosses distros and lets developers directly ship and update their own software, we just need to provide the capacity. Tech like appstream is how you enable it.
- _delirium 11y ago
  As a Debian user, that isn't really what I'm looking for. I like Debian's release management. For a stable Debian release, I don't want upstream being allowed to either: 1) push major feature and API changes, or 2) remove the software entirely. Then I'd have to deal with every random upstream's release model, whereas today I understand and trust Debian's synchronized release model. I think it's fine if this doesn't meet the wishes of how upstream wants to manage releases. Part of the point of free software is that we have a right to adapt software to serve our own needs, without needing permission of the original authors. Rolling-style releases, which get updated whenever upstream wants to push an update, are a nice option to have. But a Debian-style stable release model is also a nice option to have. So I'd like both to exist, and wouldn't want upstream package authors to be able to veto the existence of stable releases.
  - zanny 11y ago
    Its not about vetoing, it is about Debian shipping broken software that is never updated and it drives developers mad to constantly get the same bug report for the same broken feature that was fixed years ago upstream. I personally hope none of my software ends up in Debian Stable, because if it did anything broken in it at the point of freeze would haunt me for half a decade.
    - _delirium 11y ago
      Well if upstream doesn't want Debian to ship broken software in a stable version, there's a solution: upstream should improve their quality control and not ship broken software in the first place. ;) But I mean, there's no actual obligation to update software. Lots of redistributors don't update to the latest version for many reasons. Apple ships old GNU utilities because they don't like GPLv3. FreeBSD ships an old version of OpenBSD's pf firewall because their patched version is hard to forward-port. OpenBSD ships a truly ancient gcc for a mixture of technical and license reasons. And Debian updates software on a fixed stable-release cycle. I suppose it's fair that upstream can complain about this: GNU and jwz don't have to be happy that people are shipping old versions of their software. But people are also probably not going to stop doing it.

maxerickson 11y ago

More charitably, he thinks the distro choice to freeze something should result in 0 headaches for him. The idea that the freeze should be done without carefully taking responsibility for it is probably a pretty stupid norm, so I can understand the lack of patience.

zanny 11y ago

It should be perfectly reasonable, it is just that within the infrastructure of projects like Debian and RHEL there are no mechanisms for a developer to assume responsibility for their own software. The disconnect of both behavior and authority in pushing new releases vs distributing new releases is a problem, particularly for user facing applications and collections like KDE or VLC. Debian can, and should, freeze their software and provide support for what they package. But the developer should both be able to ask Debian to remove it, and to provide it themselves. But not in the traditional insanely bad and broken Windows "search the Internet for random binaries and use those" method. We have the capability, fairly easily, to provide a community repository that crosses distros and lets developers directly ship and update their own software, we just need to provide the capacity. Tech like appstream is how you enable it.

_delirium 11y ago
As a Debian user, that isn't really what I'm looking for. I like Debian's release management. For a stable Debian release, I don't want upstream being allowed to either: 1) push major feature and API changes, or 2) remove the software entirely. Then I'd have to deal with every random upstream's release model, whereas today I understand and trust Debian's synchronized release model. I think it's fine if this doesn't meet the wishes of how upstream wants to manage releases. Part of the point of free software is that we have a right to adapt software to serve our own needs, without needing permission of the original authors. Rolling-style releases, which get updated whenever upstream wants to push an update, are a nice option to have. But a Debian-style stable release model is also a nice option to have. So I'd like both to exist, and wouldn't want upstream package authors to be able to veto the existence of stable releases.
- zanny 11y ago
  Its not about vetoing, it is about Debian shipping broken software that is never updated and it drives developers mad to constantly get the same bug report for the same broken feature that was fixed years ago upstream. I personally hope none of my software ends up in Debian Stable, because if it did anything broken in it at the point of freeze would haunt me for half a decade.
  - _delirium 11y ago
    Well if upstream doesn't want Debian to ship broken software in a stable version, there's a solution: upstream should improve their quality control and not ship broken software in the first place. ;) But I mean, there's no actual obligation to update software. Lots of redistributors don't update to the latest version for many reasons. Apple ships old GNU utilities because they don't like GPLv3. FreeBSD ships an old version of OpenBSD's pf firewall because their patched version is hard to forward-port. OpenBSD ships a truly ancient gcc for a mixture of technical and license reasons. And Debian updates software on a fixed stable-release cycle. I suppose it's fair that upstream can complain about this: GNU and jwz don't have to be happy that people are shipping old versions of their software. But people are also probably not going to stop doing it.