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