Dependency Freeze Exception Request for KGet

[Albert Astals Cid]

El Dimecres, 5 de juny de 2013, a les 21:17:14, David Narvaez va escriure:
> On Wed, Jun 5, 2013 at 3:49 PM, Albert Astals Cid <aacid at 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.

Ok, seems a pretty straighforward patch so it's ok for me.

Anyone against granting the exception?

Cheers,
  Albert

> 
> David E. Narváez