On Wed, Jul 23, 2003 at 04:05:30PM +0200, Adrian Bunk wrote:
> On Wed, Jul 23, 2003 at 03:08:30PM +0200, Frank Lenaerts wrote:
> >...
> > As base is quite small, it could be released more frequently. The not
> > base part could evolve independent from the base part.
>
> Consider e.g. a g++ transition or a transition to a new version of perl:
> There is no simple way to combine parts that have finished the
> transition with parts that haven't started the transition.
Considering things like perl etc. as being part of base, this would
mean that base would first have to be transitioned. Afterwards, parts
depending on base could be transitioned.
> > The not base part could be split further into parts. These parts could
> > be things related to mailservers, things related to webservers,
> > database servers, IDS, end-user workstations, ... Because each of
> > these not base parts are smaller, they too can be released more
> > frequently.
> >...
>
> This will result in a complete chaos.
Why exactly? Just like we have had different versions of libc, gcc,
... in Debian (as a whole), we will have different versions of them in
"Debian-base" upon which the rest is built. What you mean with "chaos"
here, is what I mean with "other complexity" below.
> E.g. how do you plan to ensure smooth upgrades from any combination of
> parts to any other combination of parts?
Upgrades would only be possible in:
(1) base itself (of course)
(2) a subproject i.e. you cannot upgrade a "workstation" to a
"mailserver" branch (this would be a migration instead of an upgrade)
> > This would certainly mean lots of work, especially regarding handling
> > bugs, upgrades, security fixes, ... (as each of the subprojects would
> > have their own responsibility), but, complexity can only be resolved
> > by other complexity.
> >...
>
> Nonsense.
>
> If it's too complex, it's time to rethink and restructure the thing to
> make it simple enough.
That's what I mean. Try to remove complexity by restructuring
it. However, by restructuring things, you will also introduce other
complexities (i.e. most people feel it as complexity because it is
different/new).
> cu
cu,
> Adrian
--
lenaerts.frank@pandora.be
gpg fingerprint: A41E A399 5160 BAB9 AEF1 58F2 B92A F4AB 9FFB 3707
gpg key id: 9FFB3707
Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer
Attachment:
pgpmnnvYKDs6g.pgp
Description: PGP signature