"J.H.M. Dassen (Ray)" wrote: > > On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote: > > try this hypothetical release method out: > > > > there are two trees. let's call them devel and production. debian saavy > > folks (maintainers) run devel. new packages are uploaded to devel where > > they are tested extensivly. when a package has been in devel for more than > > (for instance) two weeks, and it has no release critical and few important > > bugs, it graduates into production. > > > > the production branch should always work. > > But it won't. This approach ignores the fact that "stability" is a property > of a release as a whole (the set of packages and their interdependencies, > ISOs, boot floppies and the upgrade path from the previous release) rather > than the sum of the stability of individual packages. > > Ray
So, that's why the current scheme is correct? It obviously suffers from latency, though it doesn't suffer from quality. It doesn't suffer from quality, because releases are being "managed", in order for a package to get into stable it has to go through extensive testing. That's in fact the main advantage of Debian. Now, how do we combine this with responsiveness, and an organic distribution like the FreeBSD? (in which there is rock-stable distro, a "working" distro, and an unstable distro, three of which are constantly developing) Here is the outline of a proposal which might do that: 1. Define subsystems within the debian system. One example is the X subsystem. However, that's too big. The point here is that the current classification of packages would be too coarse grained. I would suggest that, for instance, X applications that support gnome and are IRC clients are one class while console IRC applications are another class. A classification scheme as this would a) make browsing and finding of packages easier since it makes better use of real world semantics b) can be used to formalize things, it's just a DAG 2. Divide and conquer the release process. Define the dependencies and interfaces of each subsystem with others. Then, reorganize the release process as follows: a) A Release Team is responsible for each subsystem. The Release Team does not have to be comprised of developers of packages of that subsystem. Release Team decides which packages "graduate" to working and then to stable. Except that Release Teams may define other flavors of distributions for their subsystem. [Here I assume that package pools is working, and has three virtual distros called: stable, working, unstable] b) According to the number of packages (or the sum of "weights" of packages) in that subsystem and the number of dependencies with other subsystems (that's important), we give a weight to that subsystem. According to some thresholds, small subystems are release-managed by the smallest-weighted Team, closest up in the hierarchy. Some other thresholds may be used to indicate the importance of the release in that part of Debian. c) Debian has some serious "glueware", config tools, and a complicated package management. The policy for dealing with package management and etc. seem to be quite effective at the moment. No need to fiddle with that. However, the Debian specific software is represented also in the regular release process, and since their weights would be great their importance would have been shown faithfully. The use of these tools, and policy is made even more comprehensive and documented extensively for other developers. d) There is a System Release Team which overlooks the activities of subsystem Release Teams and coordinates them and guides them towards some goals such as the release goals that Debian had in potato. The Release Teams can have their own release policies and quality considerations, however they would have to state their reasoning. The System Release Team *doesn't* have absolute control over the Release Teams, they just represent the overall concern for Debian. 3. Implement this new scheme. In the low level, tools such as debdiff and build daemons will have significance. In the high level, package pools, release management tools, and a web based status / modular organization tool must be handled, probably the bug tracking system should interface with this tool. Perhaps, the bigger release teams must have their own mailing lists and other communication media, too. A developer should be able to find other developers' contact information easily, and participate in subsystem discussions... This is quite open-ended. A point which might strike is the existence of task packages. Don't they constitute, somewhat the required organization? The answer is both yes, and no. The task packages in their natural extension could represent "a" part-of hierarchy in Debian. However, they have overlapping parts. That's why they're not strictly part-of hierarchies. Indeed, they represent differing "user views" of the system. This might, and *must* be merged with a formal part-of and is-a hierararchy, as it might cure some of the worse pains that await Debian in the future (when we have 20.000+ packages!) I have an idea of these user views as a way to formalize the Quality Assurance process, so that it can be modularized in a way similar to the one I have suggested for the Release process. Package pools, of course, is the main issue here. It is *the* mechanism which lets developers create their own virtual distros, etc. This proposal lays out a way to combine the flexibiliy of package pools with the quality provided by the Debian releases. Comments welcome, Regards, -- ++++-+++-+++-++-++-++--+---+----+----- --- -- - - + Eray "eXa" Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED] . ^ . .