On Mon, Mar 01, 2004 at 12:10:16PM +0000, Colin Watson wrote: > (Yes, this makes release management in general a very difficult > problem, since you lose most of your degrees of freedom in the > versions available for release.) I would counter that release management may be simpler, in that specific goals for release are more granular. Each component would have its own release cycle and release manager. Teams of developers are more focused on releasing software that interests them. For this flexibility, you would increase complexity; this fact cannot be ignored. Mathematically, it looks quite scary, but would it really be that horrible in a practice? There are already numerous back-port projects out there, allowing people to install Gnome 2.4 or Apache 2 on woody. Developers WANT their software to run on multiple releases of Debian. This is also an undeniable fact. People WANT to run a stable Core and have newer software. Implementation, on the other hand, does not match Debian's current paradigm. It would be a big change internally to allow the use of components. I'm not sure how Ian is going to make it work for Progeny with the existing Debian and Fedora archives. Using our own /etc/apt/sources.list as a template, I think the current notation would change from this: deb PROTO://HOST/debian RELEASE main contrib non-free To this: deb PROTO://HOST/debian COMPONENT RELEASE_1 RELEASE_2 e.g. deb http://http.us.debian.org/debian core sarge sid deb http://http.us.debian.org/debian x11-4.3 sid deb http://http.us.debian.org/debian gnome-2.4 sarge deb http://http.us.debian.org/debian python-2.3 sarge deb http://http.us.debian.org/debian contrib sarge deb http://http.us.debian.org/debian non-free sarge *shrug* Just brainstormin'. -- Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
Attachment:
signature.asc
Description: Digital signature