Hello, should we possibly think of alternatives to the current way to present releases? I was thinking about the possibility to adopt some principles from version management that we got accustomed to in programming ...
My hunch is that everyone has a few tools that he/she wants to work on in daily routine. Those need to work no matter what - like the window manager and what is underneath. The user will be reluctant to change anything there unless there is a vulnerability of some sort, for instance. But that should be a smallish update only, no major release, and a user may have a default setting to allow smallish important updates, but object larger or non-important updates. Then there may be some other kind of software that shall be always at their latest version. Say, the boinc-client, which does not matter much if it temporarily fails or one goes back to the previous version. What today is a release, would then be a tagged set of packages, possibly implemented as a set of symbolic links to some large package archive. A new user would get that as a seed of packages. From then onwards, the apt tools would suggest only packages that are smallish updates and important to substitute the currently installed version. Upon manual initiative, the user could select newer versions for selected packages when feeling ready to evaluate something new and risk a temporal failure of some sort. Does that make any sense to you? The maintenance of a release would then mean to continue providing smallish important updates. We would still need a release team, obviously. But we would possibly concentrate more on the core functionality for defining a release, like the libc etc. When talking about a particular installation, then we would then describe it like "lenny + KDE 4". This would develop the "we release when it is ready" more towards "the users accept releases when they are ready". And, I can imagine that many more users, who are often power users of some sort, would use that opportunity to be very close to the package maintainers and to upstream while using the packages from testing or unstable, since they just do not risk that much while upgrading selected packages to the cutting edge. This would help our communication a lot. Best, Steffen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
