Re: Reduction of features

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: Reduction of features
by MamiyaOtaru on Monday 07/Jan/2008, @01:18

This is the point where I get frustrated with KDE's monolithic releases ;) I'd love to see such stuff come in without necessarily having to wait for 4.1 (and without having to run SVN). The monolithic thing just seems to slow things down sometimes. I wasn't happy at all when Kopete went into KDE, as that meant new features would only come out with KDE releases.

Obviously it works well (for all but the illogically impatient perhaps) so I'm not advocating change. I guess it's my way of saying I'm glad to hear changes are coming and I look forward to them!

Related Links

·   Articles on KDE in the News
·   Also by MamiyaOtaru
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Reduction of features
by Richard Van Den Boom on Monday 07/Jan/2008, @02:00

Everytime I build KDE from source, I'm so glad it has monolithic releases. :-)

[ Reply To This | View ]

Re: Reduction of features
by D Kite on Monday 07/Jan/2008, @07:46

Set yourself up a build environment where you can use the latest from svn code. Set yourself up a proper and robust backup method for your data.

Then run the latest and greatest. During the kde 3 development cycle I found it very satisfying to experience the maturation as it happened. And I found it surprisingly stable.

Some inside baseball: don't update during the two weeks preceeding a code freeze. It will break.

Derek

[ Reply To This | View ]

Re: Reduction of features
by anonymous coward on Monday 07/Jan/2008, @12:05

This approach usually does not work. If your preferred app resides in a KDE mayor package, you can't cherry-pick it but have to pull the hole package, which maybe only builds against the unstable trunk kdelibs, but not against any stable version. That means that you have only two reasonable options:

(1) Live on the bleeding edge and use the trunk for all your KDE apps.

(2) Wait until the next release.

A more modular approach (i.e. git repositories for each app) would allow an app to proceed at its own pace and state its own preconditions.

[ Reply To This | View ]

Re: Reduction of features
by Morty on Monday 07/Jan/2008, @13:45

This approach does usually work, even if you have to get the whole major package you don't have to compile more than the application you want. Much the same way distributions split it in to individual packages for each application. The KDE packages are very modular.

As stated the only problem you can have are when the application require functionality not present in the current stable kdelibs, but the ability to only pick the application you want makes this less likely. In the past this has even been done officially by application maintainers, for instance Kopete has been released both as part of the kde and as separate releases.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"Never miss an opportunity to throw away code." -- Guillaume Laurent
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.