On 09/19/2011 12:59 PM, Vishesh Handa wrote: > Just so that I'm clear - > > * kde-runtime/nepomuk will be deleted
yes > * kdelibs/nepomuk will not be touched and has the following libraries - > libnepomuk, libnepomukquery, and libnepomukutils yes > * All new changes will happen in nepomuk-core yes > * nepomuk-core will now contain libnepomuk2, libnepomukquery2, and > libnepomukutils2? no, only libnepomuk2 - this is currently named libnepomukcore. > * The services and other runtime components in nepomuk-core ( > ontologies, server .. ), will continue using libnepomuk? If so what is > the point of creating libnepomuk2? no, services all depend on the new lib. > * When kde-runtime 4.8 is shipped - How will the nepomuk runtime > components be shipped? as an additional package. > On Sat, Sep 17, 2011 at 9:51 PM, Sebastian Trüg <tr...@kde.org > <mailto:tr...@kde.org>> wrote: > > On 09/17/2011 04:30 PM, Albert Astals Cid wrote: > > A Dissabte, 17 de setembre de 2011, Sebastian Trüg vàreu escriure: > >> On 09/16/2011 11:46 AM, Albert Astals Cid wrote: > >>> A Dijous, 15 de setembre de 2011, Sebastian Trüg vàreu escriure: > >>>> With the currently ongoing split of kdelibs and kde-runtime > according > >>>> to > >>>> KDE 5.0 frameworks Nepomuk has already partly been reorganized: > >>>> > >>>> kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been > moved > >>>> into the new repository "nepomuk-core". kdelibs master has already > >>>> been > >>>> frozen for some time. kde-runtime/nepomuk master is now effectively > >>>> frozen as development has moved to the new nepomuk-core repository. > >>>> > >>>> Shortly new repositories as outlined in [1] will be created to > contain > >>>> the rest of kde-runtime/nepomuk. > >>> > >>> This is suboptimal regarding translations since now we have 2 > different > >>> repositories that want to create a translation template with the > same > >>> name. Please comment out or remove the Messages.sh file from > >>> kde-runtime/nepomuk > >> damn, I always forget the translations. Very sorry about that. > >> > >> Now what is the solution. To be honest I am very confused about > the 4.8 > >> release. kdelibs master is frozen. kde-runtime master apparently > should > >> be frozen but is not. > > > > There is no reason kde-runtime master should be frozen. > kde-runtime master > > will be part of the 4.8 release and has to compile against kdelibs 4.7 > > > >> There will be no changed in kdelibs for 4.8 but > >> Nepomuk needs them (well, we could do them as bugfixes in 4.7 also). > > > > Not sure I understand the sentence so won't answer. > > > >> Then what about kde-runtime master? Should we continue to work in > there > >> until 4.8? If so, I would disable translations on nepomuk-core > and only > >> enable them for 5.0. > > > > If all those nepomuk-* repositories depend on frameworks, they can > only be > > released with 5.0, so yes, we should disable translations there. > > If all those nepomuk-* repositories do not depend on frameworks > and will be > > released with 4.8 (you shall inform the release team about it > since there is > > yet another tarball to release) then you need to clean kde-runtime > because > > otherwise we will be shipping duplicate code. > > since I really do not want to maintain two branches I propose removing > nepomuk from kde-runtime master completely. > However, since nepomuk-core also contains all the nepomuk libs which are > now in kdelibs 4.7 we need to act here, too. > I propose that we move to include path nepomuk2. The main library is > already called nepomukcore. I am not sure about that yet. So maybe it > could be renamed to libnepomuk2 also. > That way we would have the libnepomuk from 4.7 and the new stuff from > libnepomuk2 and the only thing we need to ensure is that the 4.7 libs > still work with the services from nepomuk-core. Applications are then > advised to already depend on nepomuk-core instead of kdelibs. > > Opinions? > > Cheers, > Sebastian > > > > > -- > Vishesh Handa