From kde-core-devel Thu Apr 12 11:59:48 2007 From: "Christian Ehrlicher" Date: Thu, 12 Apr 2007 11:59:48 +0000 To: kde-core-devel Subject: Re: FW: [REMINDER] Upcoming KDE 4.0 Milestones + Nepomuk Message-Id: <20070412115948.44180 () gmx ! net> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117637933832277 Von: David Faure > On Thursday 12 April 2007, Andras Mantia wrote: > > On Wednesday 11 April 2007, Boudewijn Rempt wrote: > > > On Wed, 11 Apr 2007, Aaron J. Seigo wrote: > > > > i also think that holding nepomuk to the same freeze schedule and > > > > standards as kdecore, kdeui, kio may be unrealistic at any point. > > > > by delaying to 4.1 my concern is that all we'll achieve is delaying > > > > it's maturity and, due to the likeliehood of low application uptake > > > > (see my reply to dirk for more on that if you wish/need it) the > > > > odds are high that the version in 4.1 wouldn't be much more proven > > > > than a version in 4.0. > > > > > > Couldn't we just release it with kdelibs as a framework marked > > > "experimental"? There may be other candidates for that status, too. > > > > I disagree with this. People will still use it and complain after. > Too bad for them. > > > I propose kdeextragear-libs > This doesn't sound like a good place for a lib that the main kde modules > are going to need; > extragear is typically compiled -after- the main kde modules. > I've no objections against nepomuk in kdelibs as long as it works fine on win32 or is made optional. Current win32 problems (tested two weeks ago): - rcgen does not work correct (afaics a problem somewhere deep inside librdf - tested with librdf <= 1.04 ) - rcgen is created on cmake time (because it creats sources needed for cmake) - this is more a common problem and should be avoided by a dummy source file or something similar Christian -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail