On 2007-10-29, David Maxwell <david@crlf.net> wrote:
> The package authors want users to have the latest and greatest version,

Package authors want _new_ users and users upgrading from an old version
to install the latest version (on the particular branch), so as not have
to deal with old issues over and over again. Users who are happy with some
version they've installed ages ago, are free to use that version (as long 
as they don't start seeking support for it).

> The OS authors don't want to be burdened with requests for fixes to
> dependency issues by users who just want to _use_ the system and the
> package, not _develop_ them. 

OS authors shouldn't provide packages that they're not willing to
fully support. Fully supporting means that their users are aware
that they shouldn't go complain to the original author. That means
renaming when the name isn't generic (such as 'ls' etc.), or otherwise
making it very clear that they should direct all their complaints and
help requests to the OS authors. The Ion license enforces this. Let's
see how long the OS authors want to provide old versions after that,
when the upstream is no longer there to help...

> The anti-megafreeze dogma starts with the implicit assumption that all
> users absolutely want to be running the absolute latest code all the
> time. That's simply not true. Developers want that, but users do not.

Ion2 is essentially frozen, although in the highly unlikely case that
a new bug fix version was released, distros should provide those fixes.
But e.g. Debian outright refuses to fix bugs, if they're not "security"
fixes. Fuck them. 

Ion3, on the other hand, has been in "development" state for long,
and only some months ago entered "release candidate" state. Development
snapshots should not go in supposedly "stable" distributions, not if
the distro is not willing to take full responsibility for the package
(see above). Yet distros (such as Debian again) have placed ancient 
development snapshots in their "stable" (read: "static", as they don't 
care about the quality that "stable" would imply) snapshots without
even bothering to communicate with the me. Fuck them.

> I happen to agree with some of the previous comments, that 28 day update
> requirements are an unreasonable demand in a volunteer environment, but
> I think that only hurts uptake of the package in question. Packaging
> systems won't bother to include it, because the barrier is set too high,
> so fewer users will encounter it. Those who care can hand-build it.

The 28 days requirement is not for new version, but for either new
version or notifying the user that the package is probably out-dated 
and not supported by upstream. That can be done automatically by e.g.
dead man switches embedded in the package. That would be a very nice
service even for packages whose license doesn't demand it, in case
of package maintainers going MIA.

-- 
Tuomo