Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 10:49:20AM +0100, Thijs Kinkhorst wrote:
> On Mon, March 14, 2005 10:10, Ingo Juergensmann said:
> > It would be better when the project would be honest and state that it want
> > to become a x86-compatible only distribution (with the small tribute to
> > powerpc users) than this braindead thingie.
> The problems associated with carrying many archs have been well
> demonstrated.
Where?
Joeyhs wiki page about d-i problems? Oh well...
> This proposal is a way to address these problems. If you
> want to keep all archs as a part of the central architecture, you have to
> come up with a way to tackle the given problems (and not just shout that
> you want to keep them - just continuing without changing anything is not
> realistic). If you disagree, please come up with an alternative plan
> yourself (preferably a worked out plan like this one).
I already did this in the past. Read the archives for that please.
> To me this decision sounds like a very good idea. Catering to some very
> specialised architectures can be good, but should not be a great burden on
> the total project. Trying to include everything in one big distribution is
> inherently not working (as has been shown with sarge). It is very well
> possible to maintain high quality ports of Debian, and infrastructure is
> provided for that, without making the release dependant on it.
But the number of archs is not that huge problem that some people want to
make us believe.
I think the main problem is the general size of the distribution in number
of packages. You can't get 10.000 packages into a stable shape for a
release, quite simple. Therefore reduce the number of packages by
introducing a set of core packages and let the subprojects to sub-releases
when they will those are necessary.
> At the SquirrelMail project, we include things that are of general use
> into the main distribution. Someone who requires something that's only of
> interest to a very specific group can create and maintain that as a
> plugin. That seems a very logical way to deal with specialtistic features,
> and you see that approach in many different projects.
This is quite similar to my "proposal" above, where I concentrate on package
sets and not on archs.
--
Ciao... //
Ingo \X/
Reply to: