[packagekit] [GSOC] Recommender Systems

[Richard Hughes]

On 28 April 2016 at 20:17, Lucas Moura <lucas.moura128 at gmail.com> wrote:
> Does that make sense for an AppStream lib ?

So, with my upstream GNOME Software maintainer hat on:

If we're adding a dep to an extra library (especially a new one) there
has to have a compelling reason to do so, as it increases the pain for
any distributor shipping the end software. As Matthias said, from an
implementation point of view a new recommended algorithm could be
implemented as a gnome-software plugin, or could be used from
libappstream. What I wouldn't want to do is serialize the on-disk or
in-memory dump to another format and wait for results. We've got 200ms
to load the UI from cold start, and no more than 50ms to all queries
to complete -- that's not much time at all, and certainly not enough
for a C->python->C translation.

I'm really confused why a new recommendation algorithm has to have
it's own library. If the algorithm can work on either specific data or
just the unstructured search cache then it makes sense to just put it
an existing library. If 99% of the work is building a few rules and
using machine learning then it makes sense to just publish the work
and allow people to implement it in the right language, with the right
latency/memory tradeoffs, in the right layer for the application.
Spent the time making the algorithm awesome, rather that dealing with
the pain (libtool, coverity, valgrind, clang, unit tests) of writing
production-ready code.

With my Red Hat maintainer hat on:

Don't build a new project: I'm really not going to depend on any new
library when deciding which features to include in RHEL 7. This might
seem draconian, but bear in mind any libraries I drag onto RHEL we
have to do extensive security review, and then fix build errors with
newer compilers and linkers for the best part of a decade even if the
upstream disappears. Being blunt, better recommendations isn't a good
enough reason when we could just ship some static rules or allow the
vendor to override the decisions anyway.

Richard.