> On July 28, 2012, 12:36 p.m., Vishesh Handa wrote: > > I have just been informed that the tarballs for nepomuk-core have already > > been spun. Could we please please re-spin them, and include this patch. I > > don't care about the rest. They are just bug fixes. > > > > This one removes an entire class, and if KDE 4.9, goes out without this > > patch, I can never remove it. Not until Frameworks. > > Albert Astals Cid wrote: > What about things like > kde-runtime/nepomuk/kioslaves/nepomuk/kio_nepomuk.cpp ? > > Vishesh Handa wrote: > We just need to remove the headers includes. > > If it's too much of a problem, then it's fine. I'll deprecate the class > in master (or just let it be), and live with it. > > Albert Astals Cid wrote: > Do you have a list of all the tarballs that need to be remade? > > Vishesh Handa wrote: > nepomuk-core and kde-runtime. > > You'll anyway have to remake nepomuk-core for the windows stuff (if we > want, otherwise they can just patch it themselves). > > Albert Astals Cid wrote: > What about > http://lxr.kde.org/source/playground/network/telepathy/ktp-nepomuk-service/nepomuk-storage.cpp#36 > > http://lxr.kde.org/source/playground/network/telepathy/ktp-nepomuk-service/tests/storage-test.cpp#41 > > http://lxr.kde.org/source/playground/network/telepathy/ktp-nepomuk-service/tests/tid-base-test.cpp#29 > > http://lxr.kde.org/source/playground/pim/zanshin/src/itemview/itemcontext.cpp#47 > > http://lxr.kde.org/source/playground/pim/zanshin/src/itemview/nepomukcontextmodel.cpp#36 > http://lxr.kde.org/source/playground/pim/zanshin/src/utils/queries.cpp#30 > http://lxr.kde.org/source/playground/pim/zanshin/src/utils/tagmanager.h#32 > > Are we fine breaking them? > > Also can you guess-estimate the maintaince burden of this class being > present during 4.9.x? Do you forsee it breaking/causing problems/making other > fixes difficult to do? > > Vishesh Handa wrote: > The Telepathy one is my code, so I'm fine with breaking it. And I'm > positive Christian (zanshin) won't mind. I'll patch up his code myself. > > The main problem with this class is that it conflicts with the > auto-generated classes - https://bugs.kde.org/show_bug.cgi?id=232513. Not > removing it would mean finding some way to avoid the clash. Either the put > the generated classes in a different namespace or something. I'm not sure how > I'd fix it. > > In terms of maintenance effort. It's nothing. That class will just lie > there. It does virtually nothing. > > >
Ok, let's remove it, no need to have extra cruft in a library we just created to remove cruft - Albert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105755/#review16568 ----------------------------------------------------------- On July 27, 2012, 2:37 p.m., Vishesh Handa wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105755/ > ----------------------------------------------------------- > > (Updated July 27, 2012, 2:37 p.m.) > > > Review request for Nepomuk, Release Team and Sebastian Trueg. > > > Description > ------- > > No one uses it, and the same class can be generated using the rcgen. > I don't see the point of having this class. > > This is my last chance to remove this old code. Otherwise I'll have to wait > till KDE Frameworks 5. > > > Diffs > ----- > > includes/CMakeLists.txt 4ac2d7c > includes/Thing 952544e > libnepomukcore/CMakeLists.txt 066c898 > libnepomukcore/resource/thing.h 2ae3d75 > libnepomukcore/resource/thing.cpp 59f2a4d > > Diff: http://git.reviewboard.kde.org/r/105755/diff/ > > > Testing > ------- > > > Thanks, > > Vishesh Handa > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
