Dependency Freeze Exception Request for KGet

[Vishesh Handa]

On Thu, Jun 6, 2013 at 2:19 AM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dimecres, 5 de juny de 2013, a les 09:49:46, Allen Winter va escriure:
> > On Tuesday, June 04, 2013 07:03:09 PM David Narvaez wrote:
> > > Hi,
> > >
> > > I would like to request an exception for the Dependency Freeze in the
> > > case of KGet to add a dependency on Nepomuk Core and Nepomuk Widgets.
> >
> > Since other parts of KDE SC already required both of these afaik,
> > I don't think this is a problem at all.
> >
> > So request granted from me. Unless I'm completely missing the point.
>
> 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?
>

>From a Nepomuk point of view, it's mostly just a namespace change along
with 2 other changes

1. Using the Nepomuk2::Resource class instead of Nepomuk::Resource - The
former has unit tests and has a huge number of fixes for crashes. Also,
it's a lot faster.

2. Moving away from MassUpdateJob - Nepomuk2 was specifically introduced to
use  asynchronous calls. The MassUpdateJob was synchronous with some hacks
to make it non blocking. KGet now uses the proper asynchronous APIS. There
same APIs are used by the Resource class, and Dolphin in order to handle
bulk operations (since 4.10).

So you can only become more stable!


> Cheers,
>   Albert
>
> >
> > > The situation is that KGet already provides Nepomuk integration, which
> > > provides features like auto tagging and download history. I worked on
> > > restoring the download history code, which was more or less broken,
> > > for KDE SC 4.10 but made a note to port the trunk version to Nepomuk2
> > > to avoid some quirks that will not be fixed in Nepomuk. Unfortunately,
> > > I had very little time to hack on KDE the last couple of months and I
> > > just found time to do the port. It would be good to have this go into
> > > the betas for KDE SC 4.11 to have more time to test, but I'm very
> > > confident that this code is working since the migration is more or
> > > less automated by now.
> > >
> > > To clarify, this does not introduce any new feature to KGet, just
> > > implements the same optional Nepomuk features using Nepomuk2 which is
> > > actively maintained and improved. I'm CCing Lukas Appelhans, the
> > > maintainer of KGet (who agrees with introducing this dependency) and
> > > Vishesh Handa who is maintaining Nepomuk2.
> > >
> > > I am open to any questions or clarifications.
> > >
> > > David E. Narváez
> > > _______________________________________________
> > > release-team mailing list
> > > release-team at kde.org
> > > https://mail.kde.org/mailman/listinfo/release-team
> >
> > _______________________________________________
> > release-team mailing list
> > release-team at kde.org
> > https://mail.kde.org/mailman/listinfo/release-team
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130607/0725ff75/attachment.html>