Mailing List Archive

Chris Bainbridge posted
<623652d50604040212r6f543d37pedb645e979456755@mail.gmail.com>, excerpted
below, on Tue, 04 Apr 2006 10:12:21 +0100:

> I think at this point it does more harm than good to be lagging behind the
> current upstream kde - last time I checked the kde bugzilla wouldn't even
> accept bug reports for the kde currently marked stable as it was too old,
> and if bugs can't be filed then it's clearly "unsupported upstream" and
> time to upgrade.

Wow! I run ~arch by choice and generally find its keywording suitable
(IOW, packages move from masked to ~arch at a generally appropriate
speed), but I didn't realize Gentoo KDE-stable was /that/ far behind!
Point well made!

--
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

Donnie Berkholz posted <44320F27.8000003@gentoo.org>, excerpted below, on
Mon, 03 Apr 2006 23:16:07 -0700:

> Duncan wrote:
>> The Gentoo-desktop list is lower volume and generally where I ask
>> (developer level) questions about anything so related, KDE, GNOME,
>> burning CD/DVDs, sometimes sound issues, etc. Again, that's a developer
>> list not a general user list, but it's low enough volume and generally
>> friendly enough to get you the answers you need if it's something (like
>> this) a dev would need to answer.
>
> Really it's both developer and user questions. It's just that the
> uninteresting ones tend to get ignored for a while because they aren't fun
> to answer for the 10th time or so. =)

That's sort of what I meant, but it wasn't wording quite right and I
didn't want to take too many liberties as user so I erred on the side of
caution. Thanks for the clarification. =8^)

(BTW, altho devs will know this already some users reading this may not,
Donnie B is the Gentoo Desktop project lead, so that's straight from the
source. =8^)

--
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

Diego 'Flameeyes' Pettenò posted
<200604040843.09697@enterprise.flameeyes.is-a-geek.org>, excerpted below,
on Tue, 04 Apr 2006 08:42:56 +0200:

> On Tuesday 04 April 2006 08:09, Philip Webb wrote:
>> KDE is now modular: is it possible to upgrade some modules, but not
>> others ? Kdelibs would need to be stable, but must everything wait for
>> stragglers ? If I have Kdelibs 3.5.2 , can I still run eg Konsole 3.5.1
>> ?
> As modular as it can be, it has to go stable in one piece.

PW: Note that while Flameeyes' is correct from a dev perspective (it's
modular but there's a large degree of interdependence, so not stabilizing
it as a unit is asking for trouble), they /do/ "skip" certain packages in
the upgrades (within slot, 3.4 is a different slot than 3.5, but 3.5.0
thru 3.5.2, currently, are all the same 3.5 slot) -- those where there's
no new code and where the dependencies are stable enough that a recompile
against the new ones isn't required. In fact, that was given as one of the
big reasons for going modular in the first place.

From a Genntoo user perspective, again within the same slot, once you've
upgraded arts (if you use it) and kdelibs, you can in general continue to
use a mix of old and new while you upgrade additional packages one at a
time. I do this routinely for a few hours during the upgrade as
the rest of the new KDE is still merging. Sometimes one or another binary
or particular function will stop working temporarily until it and all the
pieces it depends on are upgraded as well, but most stuff continues to
work well enough to continue to use. Just don't go filing bugs on anything
that breaks until the whole set is updated.

--
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

(sorry if you receive this mail twice, my subscription was not ok)

Philip Webb wrote:

> 060404 Caleb Tennis wrote:
>> historically we were much more bleeding edge with our stable KDE
>> versions, but if you've spent any significant time playing with 3.5.0 or
>> 3.5.1, you would agree that they are terribly less stable than 3.4.3.
>
> Not here !  I've used both (successively) every day
> & can't recall a single crash or noteworthy (indeed any) problem.
> It's true that I don't use Kmail & similar exchange-type apps
> & some comments suggest that is where the bulk of instability lies.
>
> The fact that KDE itself is no longer accepting bugs for 3.4.3
> really does suggest there's something wrong with Gentoo's current
> criteria.
>
As a user I have to add my opinion here. I have been using Gentoo for some
years now and it was always fairly up to date. Currently KDE is really
behind on the current situation upstream.
And then I wonder why. What makes us think we can not trust the KDE devs?
Does compiling KDE introduce so many bugs? I mean, let's be serious, all
other distributions have a stable 3.5.x now. Don't they experience all
those horrible bugs?
Seriously, this is really becoming an issue. As I pointed out in a bug I
filed for a stable KDE (for which I apologize, I should have looked here
first), some people are leaving Gentoo because of this slow upgrade
process.
The classical answer from devs is "it's ready when it's ready". From a user
point of view this is very, very vague. Please give users a more clear
explanation, this creates great frustration when looking at other
distributions. Because it's stable there.

These are my 2 cents as a user. One that loves Gentoo. One that loves KDE.
One that's frustrated by the current situation. I am a CS so I know how
hard programming can be, don't get me wrong there. I do appreciate what you
guys do. But I can't understand why you do it this way right now.

Bart

--
gentoo-dev@gentoo.org mailing list

Bart Braem posted <e3cplj$jv3$1@sea.gmane.org>, excerpted below, on Thu,
04 May 2006 13:48:03 +0200:

> As a user I have to add my opinion here. I have been using Gentoo for some
> years now and it was always fairly up to date. Currently KDE is really
> behind on the current situation upstream.
> And then I wonder why. What makes us think we can not trust the KDE devs?
> Does compiling KDE introduce so many bugs? I mean, let's be serious, all
> other distributions have a stable 3.5.x now. Don't they experience all
> those horrible bugs?
> Seriously, this is really becoming an issue. As I pointed out in a bug I
> filed for a stable KDE (for which I apologize, I should have looked here
> first), some people are leaving Gentoo because of this slow upgrade
> process.


I'm just another user, not a dev. Please keep that in mind as you read
the following.

That KDE was two releases behind, even on cooker for AMD64 (which
unfortunately followed stable for i586, not cooker for i586), was the
reason I left Mandrake, so I know exactly where you are coming from.

That said, you've hit a sore spot -- illogical people asking for
something, choosing it when given the choice, and then when they get it,
complaining about what they chose in the first place, when the other
choice remains right at hand for them to change their mind and switch to
at any point! Exactly that -- illogical!

/Why/ are people leaving over this?? The ebuilds are there in ~arch and
have been for some time. If people want cutting edge, Gentoo continues to
provide pretty damn close, often having (still masked because upstream
isn't available at the time) ebuilds in the tree even before public
release, as I know for a fact has been the case with KDE, as I've seen the
ebuilds and the masks there, before the releases, complete with the reason
for masking given as upstream not released yet.

Stable is there if they want it, too. They can choose to run stable.
There's nothing wrong with that, just as there's nothing wrong with
making an informed decision to run unstable. If they want to leave for
some other distribution, for whatever reason, that's fine and good. There
are legitimate reasons to do so, places (like binary packages and
periodic releases with few updates between them) where Gentoo isn't as
strong, because it chooses other areas to emphasize. Deciding to stick
with (IMO consistently outdated, but hey, if people want stable...)
stable, then being unhappy with devs for not choosing to stable-keyword
something with known issues, isn't such a legitimate reason, when they
have the choice to upgrade at any time they choose, regardless of stable
status, as the ebuilds are there for them to do so and the general Gentoo
documentation is clear in its instructions as to how to do so, if desired.

It's up to an admin whether they want to risk running unstable on nothing,
individual packages, whole categories (kde-base) of packages, or their
entire system. Why then are those same admins complaining when devs take
their responsibility to do the best they can to ensure something's stable
before marking it such, seriously. I can envision the /same/ admins
complaining that the devs didn't do their job if the issues remained and
the packages were stabilized even with known issues.

As for trusting or not the KDE devs, that's not the issue. Either there
are still known problems on Gentoo, or there aren't. It doesn't matter
if those were upstream problems or Gentoo problems, in this case, only
whether there are problems on Gentoo or not. As it happens, many of the
problems with 3.5.0 were upstreamm and have been resolved with 3.5.1 or
3.5.2. That took time. 3.5.0 won't ever make stable as it has issues since
fixed with further upstream releases. 3.5.1 likely won't either. 3.5.2 has
fixed many/most of them, but it hasn't been much more than 30 days since
its release, and Gentoo normally requires a package to be bug-free for 30
days in ~arch before going stable, so it's only now qualified.

Meanwhile, those who want to risk running the unstable packages and are
willing to live with or provide patches for the bugs (bugs which after
all are there in bugzilla, if anyone wants to know what the holdup is)...
can do just that since the ebuilds are there from the day of release and
often even /before/ release! That they don't choose to do so is their
choice and their responsibility, not that of Gentoo.

Note that due to Gentoo slotting, it's not even necessary to give up the
stable KDE to merge the still unstable version! With slots, they can
exist quite well in parallel.

Now it'd be rather different if the ebuilds weren't there. As I said, I
left Mandrake over such things. However, they /are/ there. The choice to
merge them or not is the user/admin's. If they chose not to do so, why
are they then blaming Gentoo for their own choice?

--
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

Michael Kirkland wrote:

> I think the problem is that Gentoo is falling into the same sandtrap the
> Debian project has been mired in forever. "arch" and "~arch" are
> polarizing into "stable, but horribly out of date", and "maybe it will
> work".
>
> This leads to people trying to maintain a
> frankenstinian /etc/portage/package.keywords file, constantly adding to it
> and never knowing when things can be removed from it.
>
> I would suggest opening a middle ground tag, where things can be moved to
> from "~arch" when they work for reasonable configuration values, but still
> have open bugs for some people.
>
> That way, people who prefer stability over the latest features can run
> "arch", and everyone who bitches about packages being out of date can run
> the middle tag, and "~arch" can be kept for testing.

I really, really agree here. I know this seems like a flamewar but it is
starting to annoy me. There are several packages that are several months
behind the official releases. I am going to name some of them:
Firefox 1.5: 5 months (the entire world uses it now, in stable)
KDE 3.5.2: 1.5 months (I know our devs get prereleases, so we had this time)
Xorg 7: 5 months
I know we have a lot of work to do, but I have some concerns. How long are
we going to maintain old packages? KDE 3.4.3 is no longer supported by the
KDE developpers. Firefox extensions for 1.0 are becoming extinct.
You are also getting a lot of work trying to fix bugs in old software. Most
probably you are starting to backport bugfixes, is this the way we want
things to go?
I understand you don't care about how many users you have, Gentoo is not a
bussiness. But if I try to convince users about the current situation that
is hard. I can't explain this, I really can't. My only answer is "put it
in /etc/portage/package.keywords". But that one is growing very fast...
One nice thing for users would be the addition of more metabugs for recent
packages. I'd like to know why some packages are not stable, and I am not
the only one. Adding a metabug instead of closing all requests for
stabilization with wontfix/wontresolve is much more userfriendly.

Once again, I love to use Gentoo but I don't understand the current
situation. I have the feeling that I'm not the only user so I posted these
comments in order to discuss them. Hopefully you don't mind trying to
explain it all...

Bart

--
gentoo-dev@gentoo.org mailing list

Philip Webb posted <20060505073706.GB6335@sympatico.ca>, excerpted below,
on Fri, 05 May 2006 03:37:06 -0400:

> That's very much my own impression. I am now using ~x86 versions of Vim
> Vim-core Gvim Cdargs Openoffice Eix Euses Gqview Gwenview Portage Firefox
> Galeon Htop KDE -- all of which which I use regularly -- & Abiword
> Gnumeric Koffice Gnugo Qgo Qalculate-kde (which I rarely use). I have had
> no problem with any of them.
>
> My solution is a line in .bashrc :
> 'alias emergeu='ACCEPT_KEYWORDS="~x86" emerge' ,
> which allows me to emerge a testing version on a specific occasion. The
> package.keywords alternative is silly, as there's no reason anyone would
> want to do it regularly for a package, as opposed to occasionally when --
> increasingly -- stabilisation is late.
>
> I do a weekly 'eix-sync' & check the list of packages which have changed,
> then decide which ones to update; I never do 'emerge world'. I keep an
> upto-date file with a line for each package I have installed, incl date,
> version & the main dependencies it satisfies (if any): this is my
> alternative to 'world', which is clumsy & causes problems.
>
> I have been doing this since I started using Gentoo in Oct 2003 & have
> never had any problem with Portage or packages as a result.

Here, I simply use ~amd64 for my entire system, and rarely have problems.
When I do, that's what those backup snapshot partitions I keep around are
for.

Gentoo is really fairly conservative with ~arch. That does /not/ mean the
package is broken, or the upstream package is unstable. Rather, it means
the upstream package is reasonably stable, and the Gentoo ebuild is known
to work and is tested at least by the Gentoo maintainer.

Really broken packages and packages known to have very serious issues on
Gentoo aren't ~arch at all, but are instead hard-masked, either with the
-* keyword, or with an entry in package.mask.

Given these facts, I'm of the opinion that most of those running stable
that are calling for faster package stabilization, should really be
running ~arch. That's doubly true for those finding they have an
ever-growing package.keywords and/or those calling for a "middle" keyword.
In point of fact, ~arch /is/ that middle keyword, because the really
unstable packages are hard-masked and not in ~arch in the first place.

Actually, I run selected hard-masked packages as well. Particularly with
things like gcc, which is slotted and easily managed with gcc-config or
eselect compiler, it's quite easy to run hard-masked stuff in parallel.
Something like xorg isn't as easy to run in parallel as it's not slotted,
but even there, given FEATURES=buildpkg, if one has the time and
motivation to test a masked version, it's relatively painless to revert
to an old version if the test doesn't work out so well (with the caveat of
course that one keeps backups, as one should anyway, in case something
goes /really/ wrong -- it IS hard-masked packages we are talking about
now, after all).

Again, I don't see the problem. Stable is there for those that want it.
~arch is there for those that want something newer, with a bit of extra
risk. Hard-masked-for-testing packages are very often there for those who
REALLY want bleeding edge -- along with the associated increase in risk.
If folks don't like how far behind stable is, and are willing to risk not
only their own systems with the package in its current state, but the
systems of everyone else running stable (which is what requesting faster
stabilization actually comes down to), they shouldn't be running stable
after all, but the "middle" keyword, that being ~arch. That way, they get
their newer, mostly stable programs, while everyone who /really/ wants
stable doesn't end up with the risk of stabilizing the package too fast.
Of course, note that package.keywords works both ways. Folks running
~arch as their regular keyword can set specific packages to arch (stable)
in package.keywords too. Again, Gentoo is very flexible in that regard --
some might say insanely flexible, but it works, if people would only read
the docs and follow them as appropriate.

--
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

Donnie Berkholz wrote:

> Bart Braem wrote:
>> Xorg 7: 5 months
>
> Can't stabilize till portage 2.1 is stable. Doesn't matter how many open
> bugs we've got, or how well it works.
>
Thanks for the explanation. Not that I really like it but I understand that
portage 2.1 is a large upgrade...

Bart

--
gentoo-dev@gentoo.org mailing list

Jeff Rollin posted
<8a0028260605042228t625ca152p25d65cd6bb9c8e72@mail.gmail.com>, excerpted
below, on Fri, 05 May 2006 06:28:53 +0100:

> Or maybe we could move to a fixed release cycle. Debian uses 18 (?)
> months, but maybe a 3- or 6-month release cycle would suit us better

Actually, Gentoo already has that, altho the period is still getting
tweaked occasionally. That's what the 200X.Y releases are, with the
LiveCDs and stages, and the PackagesCD with its precompiled stuff, for
those who want to go that route. In 2004, there were four quarterly
releases, 2004.0-2004.3. In 2005, they reduced that to two semi-yearly
releases, 2005.0 and 2005.1 (with a 2005.1-r1 coming out soon after, with
limited changes fixing limited bugs). In 2006, the target is again two
releases, the first of which, 2006.0, has already occurred. Thus, it
looks as if the 6-month cycle seems to be suitable for the time being.

Of course, one of the big benefits to Gentoo is that it's not the jerky
upgrade/wait/upgrade cycle other distributions tend toward, but more a
continuously upgraded system, with the periodic snapshot releases simply
being exactly that, snapshots of the tree that have been fairly well
tested on a particular arch and found to work reasonably well as a place
to start. Once the system is up and going, the assumption is that folks
will update at least a time or two between snapshot releases, with many
updating twice weekly to daily. The more frequently you update,
generally, the smoother the updates will be, because it won't be such a
big jump all at once.

Within that system, what's stable at the particular snapshot date gets
tested and included in the stages, and live and packages CDs. There is of
course some push to get stuff stable by a particular release, but that
pressure hits Gentoo sponsored and targeted projects like portage and
baselayout the hardest, with the vast majority of packages affected more
by the timing and releases upstream than by Gentoo's snapshot releases.

That's part of what makes Gentoo Gentoo. To change it changes the Gentoo
we know into something else -- /not/ the Gentoo we know. I doubt you'll
find much support for significant change among Gentoo devs /or/ users,
because after all, if they didn't like it, they'd not have chosen Gentoo
in the first place, as that's one of the defining characteristics that
makes Gentoo what it is.

--
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

Caleb Tennis wrote:

> Get involved.  It's the only way you will truly understand the magnitude
> of a project like Gentoo.  KDE is a very small slice of the whole thing,
> and yet it still requires a LOT of time.  We're always looking for help.
> If you need a place to start, pick out a bug report and try and fix it.
> You might spend 3-4 hours chasing the answer.  3-4 hours.  Can you imagine
> sitting in front of your computer for 3-4 hours to solve a problem for
> someone you don't know for no compensation?  And you may never even figure
> it out!
>
> So let's rephrase "why doesn't Gentoo have ZZZ" into "how can I help
> Gentoo have ZZZ?".  Become empowered.  That's what will keep the
> distribution great.
>
>
> Caleb
>
>
> My guess is that KDE 3.5.2 is probably ready for stabilization, but nobody
> has the time to do it at the moment.  That's purely a guess, though.  Feel
> free to open a stabilization tracker bug for it so we do have a place to
> discuss it.
>
You know, that's why I came here. I opened a bug (#132213) where I suggested
to open a stabilization tracker bug if necessary and the bug was closed. I
was referred to this thread...
I feel that if more packages would have a stabilization tracker bug things
would be more clear for users. That would make it a lot easier to help
solve bugs. I users start asking for more stable packages you can refer
them to those bugs. And then they can help. And most probably I would help
more too.
I don't have much spare time either, but if I want something done in my
distribution and I can help I would do that faster.

Bart

--
gentoo-dev@gentoo.org mailing list

Bart Braem posted <e3f37g$uqo$1@sea.gmane.org>, excerpted below, on Fri,
05 May 2006 10:43:28 +0200:

> Donnie Berkholz wrote:
>
>> Bart Braem wrote:
>>> Xorg 7: 5 months
>>
>> Can't stabilize till portage 2.1 is stable. Doesn't matter how many open
>> bugs we've got, or how well it works.
>>
> Thanks for the explanation. Not that I really like it but I understand
> that portage 2.1 is a large upgrade...

That of course begs the question of portage 2.1 stabilization.

FWIW, as a (mostly) lurker on the portage-devel group/list, I believe
it's safe to say that 2.1-rcs are "coming real soon now". There's an
active discussion at the moment on whether to base -rc1 on -pre10, which
introduced some code cleanups, -pre9, before those cleanups but after the
intro of manifest2 (a big target feature that needs included, but that
will mean a bit longer to stabilize), or -pre7, before manifest2. Whatever
the decision, portage trunk is now feature-frozen until the split is made,
so the 2.1 stabilization process is now started.

The target is stabilization of 2.1 for Gentoo 2006.1, penciled in for
release this (northern hemisphere) summer (July-ish, AFAIK). Assuming
that target is hit, Donnie should be able to say whether xorg 7 should
stabilize at the same time and be ready for 2006.1 as well, or whether
it'll be slightly behind, perhaps 30-days or so -- IOW, whether its 30 day
stabilization is in parallel to or occurs after the 30-day stabilization
of portage 2.1.

In any case, given his statement above and the events from portage-devel,
a reasonably safe prediction should be that they'll both be stable by the
end of the (northern hemisphere) summer, with a target of mid-summer.

--
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

Carsten Lohrke wrote:

>> KDE 3.5.2: 1.5 months (I know our devs get prereleases, so we had this
>> time)
>
> Still open issues, some upstream, some Gentoo related. Also the KDE team
> lost members the last months and is unfortunately not that active since a
> while. All the whining leaves me with the feeling that I'm less interested
> to work for you. The question "What can I do?" I do never hear. Stop
> whining, but decide to help or give another distro a try. These are your
> choices.
>
(As I mentioned in another post, I did ask for a metabug to help.)
I have other OSS I work on. The "what can I do" question is not relevant
here because I simply can not make the commitment. I posted this questions
as a user, not all users have the time.
And I'll try to repeat: I'm not whining, I'm just asking for a reason. I did
not know that some developpers left recently and now I understand the
situation. I did not know Gentoo had those problems.

So my suggestions:
- Document the use of ~arch better. It seems to me that the arch tree is
more stable now and that the idea of ~arch which was very broken years ago
is now more stable. (I'm a user since 1.4rc3)
- Open more metabugs that document the requirements of stabilization for the
largest packages. Report about that policy to all users and actively ask
them to cooperate there.

Bart

--
gentoo-dev@gentoo.org mailing list

Diego 'Flameeyes' Pettenò posted
<200605061341.56971@enterprise.flameeyes.is-a-geek.org>, 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