On Fri, 2004-12-10 at 12:50 +0100, Michael Banck wrote:
> On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> > Let me first say unequivocally that the LCC is very interested in
> > getting Debian involved. The question has always been: How do we do
> > that?
>
> I think there is one obvious answer to this question: 'Learn from
> history'.
>
> 1. Unix and UnitedLinux failed. LSB party succeeded but has no practical
> importance.
>
> 2. GNOME succeeded for the desktop.
>
> The reason why the above failed have already been outlined in this
> thread and one quote from Bruce sums it up pretty well: 'The members
> considered that they had proprietary value at the level at which they
> were collaborating.
>
> The reason why GNOME succeeded is because it builds a solid, predictable
> and free base for vendors and distributions to build on. Every major
> distribution which is interested (mostly RedHat, Novell and Sun) has
> people working on GNOME and collaborating with each other.
>
> The other reason why GNOME succeeded is because it spectacularly managed
> to reinvent itself to make it feasible for others to build upon it.
> Before those mentioned above used GNOME as their base, it was pretty
> much similar to what Debian is today: No proper release schedules,
> delays and not much of a broad and far-reaching vision.
>
> So I think the obvious conclusion to the above answer ('learn from history') is:
>
>
> *** The interested parties of the LCC should pick Debian as a base and
> Debian should make this possible. ***
Woooo, that would be tough. But I like it. At least for Core.
> Rather than everybody just throwing all their stuff in together and
> mixing it up.
>
> Of course, this would also mean for Debian to change. Debian is free
> and solid today, but not predictable. Thus:
>
> * We should commit to strict release cycles of a base system others
> (and Debian itself) can build value upon.
So we would detach "Core" from everything else, perhaps we should also
then also define kernels with specific patches to accommodate certain
situations or applications. IOW have flavours of kernels be something
like:
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<db-name>
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<app-server>
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<erp-solution>
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<web-serving>
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<transaction-processing>
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<workstation>
kernel-image-<kern-ver>-<rev>-<arch>-<up/smp/mpp>-<gaming>
kernel-image-<kern-ver>-<rev>-<up/smp/mpp>-<generic>
With those Distributions needing keeping the base-patchset up-to-date
and while the buildd machines compile for the architectures, While we as
Debian just continue on managing these patchsets to work on all arches.
This would require those other Distros to become more policy driven. How
would we split this out? Would we then have "Core Only DDs"? Would we
still have the ability to get security fixes out the door in time?
Should we do revision releases like say we do for Woody right now:
3.0r1/2/... would this work? Doing incremental security/major bug-fix
releases similar to the way Microsoft does it? (No not really, but the
idea is similar) Should we then have a "Core Only"
Stable/Testing/Sid/Experimental?
> * We should probably also commit to a set of core architectures which
> *need* to be bug-free on release, while the rest *should* be, but
> would not delay the release.
I disagree here, when WOULD they get worked on then? Release pending is
a good motivator. But as we see now, it is not *THE HOLY GRAIL* of
Motivators. Some of the *OLDER* not able to keep up as of now anyway
buildd machine arches might be candidates, but Dang what a way to slam
the door on them. (like 32bit Sparc, M68K, others)
> * We should look into having a reality-check with respect to licensing
> and the way we treat each other.
Now this... needs to happen anyway.
> On the other hand, this would also mean: The other partners should get
> involved into Debian development, both by getting their toolchain/base
> developers into the Debian project and possibly accepting Debian
> developers into their ranks.
Again, this should happen period.
> All this could not be done easily, but it is the only viable solution
> for a solid, free and predictable base system. There is no alternative
> to it.
Unfortunately, this I agree with you. It will make it the toughest thing
on the planet. A sub-structure of Buildd will need to make both DEB
packages as well as RPM, lest we not forget, TGZ/other packages mgmt
systems.
This is a big job, which I believe nobody will succeed on. Which is tooo
bad.
--
greg, greg@gregfolkert.net
The technology that is
Stronger, better, faster: Linux
Attachment:
signature.asc
Description: This is a digitally signed message part