Diego 'Flameeyes' Pettenò posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 06 May 2006 13:41:50 +0200:
>> Any stable version of KDE will need kdelibs kdebase , but otherwise why >> can't the packages be made stable at least as each big downloadable file >> becomes ready, if not individually ? > Because they have to be stable at once. Period. > > Can't go stable piece by piece. Period. Can't. Period. Elucidating a bit for Philip. You are likely aware that the packages forming kde-base are uncommonly inter-dependent on each other. That's because KDE by design is very modular, with various pieces calling parts of other packages to do what they do best, increasing code reuse and decreasing unnecessary duplication and reimplementation of features. Most KDE users find that to be one of its strong points. However, what it means to a dev is that due to that very high degree of interdependency, while a few packages could be version pick-and-chosen at the user end and have it still basically work, that cannot and will not be a general policy, because tracing bugs would then be what would amount to an impossibility. Little dependencies not normally seen and never tested because testing both upstream and at Gentoo is per release, could and almost certainly would easily multiply bugs like the tribbles of startrek -- without end. It's a QA and testing nightmare that's easily avoidable by simply refusing to stabilize a release piecemeal. It's not just kdelibs and within the big category tarballs that the problems occur, either. In ordered to work properly, as you stated, many of the newer components depend on the newer kdelibs as well. So far so good. However, some will depend on various parts of kdebase (that's the tarball from upstream, not the kde-base Gentoo category) as well. However, that's not the end of it, because once you upgrade kdelibs and parts of kdebase, you are now running anything /not/ upgraded on a kdelibs/kdebase that it's never been tested with. Further compounding the problem, due to the interlinking of various components, it's actually very likely you'd have an upgraded application trying to work with an old kpart depending on an already upgraded part of kdebase depending on another part that wasn't upgraded, depending on the upgraded kdelibs! How on /earth/ do you propose to logically bugtrace /that/ sort of mess!? The answer is, it's simply not possible! The /only/ sane policy under those circumstances is to stabilize the entire release as a single unit. If a single part of it can't be stabilized, that means the entire release is held back and cannot be stabilized. Like it or not, that's simply part of living with and working with KDE -- the flip-side of all those nice features that interlock so well and work so seamlessly together. That's the reasoning behind "Can't go stable piece by piece. Period. Can't. Period." Indeed, in this case, "Can't. Period." is the absolute truth, to the the point that to to a developer, no more need be said, as it's simply uncontemplatable. Take those assumptions away, and there's simply nothing left to build upon or debug with. You might as well be trying to debug random bits -- the supporting logic and assumptions are that far gone. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
