On 2007-03-05 17:28 +0100, Bernhard R. Link wrote: > Having things not mega-freezed means > either having to watch for important changes (like, say, > no longer starting in default configuration) throughout > the whole year, or just throwing unusual stuff out of the > supported pre-installed pool of software.
Having things not mega-freezed, means that the upstream doesn't have to listen to complaints of _old development snapshots_ that the upstream is no longer supporting. Get it? Not every software release is a "stable" release that the upstream is willing to support for very long. During the process of trying to eventually provide a stable release, you make "development snapshot" releases for the users who want to be on the bleeding edge, but not directly build from the version control systems. That is the state of Ion3: development/unstable. Only an idiot would provide it in a "stable" distribution. Ion2, on the other hand, is "stable", and will not go through major changes. However, even Ion2 should be upgraded in distributions, if there's a new release (very unlikely), because due to its "stability", any upgrade will be a rather critical fix. Distributions should be attention to the stable/unstable state of the upstream packages. If the upstream package is "stable", then it can be included in the distribution's "stable" collection, and the few upstream upgrades should also be safe to include in an upgraded collection. If, on the other hand, the upstream package is in "unstable/development" state, the distribution should also only include it in an "unstable" extras collection. I have been considering adding something like the following to the Ion3 license. If it is against the DFSG, well, the effect still be the intended. --- This work, "Ion3", is licensed under the GNU Lesser General Public License (LGPL), reproduced below, extended with the following "Distributor timely response clause" (D). D. Anyone distributing Ion3 in aggregate with other works, must within twenty-eight (28) days from the release of a new version of Ion3, either (A) upgrade the aggregate to include the new version, and cause the new version be installed when a user tries to install an unspecified version of Ion3, or upgrade Ion3 (from the aggregate); or (B) remove Ion3 from the aggregate, and notify users of the removal, when they try to upgrade the aggregate or Ion3 (from the aggregate) and have installed an old version of Ion3. (It is, however, not necessary to remove Ion3 from the user's computer; merely notify of its out-datedness.) The requirements above on responses to user actions do not apply, if the user is not network-connected, or chooses to not use network upgrades, and is using physical distribution media. This clause does not bind any rebranded derivative works, that can not be confused with Ion3: that is, any derivative work whose name can not be confused with "Ion3", and whose listed maintainer (in the README) is different from that of Ion3, may be distributed under the LGPL or GPL without this clause. --- So, if you're willing to take all the blame for the outdated development snapshots that you want to provide, just rebrand and start maintaining it yourself.. -- Tuomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]