Dependency Freeze Exception Request for KGet

[David Narvaez]

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.

David E. Narváez
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _kget-nepomuk2.diff
Type: application/octet-stream
Size: 30805 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130605/c15b1f5d/attachment-0001.obj>