On Wed, Jun 5, 2013 at 3:49 PM, Albert Astals Cid <aa...@kde.org> wrote: > The point here is that I don't think the problem here is the Dependency Freeze > but the Feature Freeze. > > Ok, this is not a "new" feature, but introduces (i guess) a reasonable chunk > of new code to implement the same feature. To me that still seems like a new > feature, so could you guys comment on the impact of "what if the new code we > are adding is really bad". Would KGet crash like crazy all the time or one > would just lose the nepomuk features?
Not really, that'd be r1345874 in the 4.10 branch. This change actually ports r1345874 to trunk, so in general the code will be exactly as we have it right now on 4.10 except for the following 3 exceptions: - At void NepomukStore::saveItem(const TransferHistoryItem &item) the line historyItem.setProperty(Soprano::Vocabulary::RDF::type(), Nepomuk::HistoryItem::resourceTypeUri()); found in 4.10 is not included in trunk because this was used to work around a bug in Nepomuk which no longer exists in Nepomuk2 - The changes from Nepomuk namespace to Nepomuk2 namespaces (this is the only thing that makes the patch look large and intimidating) - At void NepomukController::setProperties(const QList<KUrl> &uris, const QList<QPair<QUrl, Nepomuk::Variant> > &properties, const QUrl &uriType) the use of Nepomuk::MassUpdateJob was removed in favor of the Nepomuk2 DataManagement API which does the same (async) work. I would agree to consider this particular change a new feature, so it is a good idea to analyze what can go wrong here: This tags are applied when you configure a group to automatically tag transfers in that group. This would work with the new code (I've tested it) if it wasn't for the fact that you almost cannot configure a group for autotagging right now because of a separate bug. Since this bug hasn't been reported, I expect that an issue around this piece of code would not be of great impact because this feature doesn't seem to be widely in use. In fact, the whole Nepomuk integration was not working at all for some time until r1327893 and went unnoticed for a couple of months, so that should give us an idea of the potential impact of an issue with this code. Let me know if you have any questions. I'm attaching what would be the patch to do the migration. David E. Narváez
_kget-nepomuk2.diff
Description: Binary data
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team