Re: [Tracker] The Big Rip

[Debarshi Ray]

Hey,

On Fri, Oct 28, 2016 at 02:34:03PM +0200, Carlos Garnacho wrote:
> - nautilus tagging extension: Another one I have a hard time caring...
> If this feature is as desirable, should be implemented in nautilus
> itself (and most likely with better looking and more integrated
> results). I'll probably split it, make a release, and never revisit
> again. As above, maintainers welcome.

Please feel free to remove this.

I wrote this code 7 years ago before GNOME 3 existed and I don't think
anybody really cares about it. It never grew beyond the 'cool demo'
phase. If we really need the functionality today then it would need to
designed and be directly integrated into Nautilus or Totem or
whatever.

Cheers,
Rishi

signature.asc
Description: PGP signature
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] The Big Rip

[Adrien Bustany]

Hi Carlos,

I'd totally be fine axing the Firefox and Thunderbird plugins, they 
shouldn't really be core parts of Tracker.


Cheers

Adrien


Le 28/10/2016 à 14:34, Carlos Garnacho a écrit :

Hi all,

It is well known that Tracker has been accumulating lots of code and
features over the years, with greatly varying states of maintenance.
There's been earlier talks in this ML about splitting the whole thing
into more palatable chunks, some refactoring happened towards making
this easier, but it was never accomplished.

So I'd say now is just as a good time as any to finally do this, I've
pushed (so far) the following WIP branches I worked on the last couple
of evenings:

- wip/split/core : contains Tracker "core", most notably
tracker-store, ontologies, libtracker-sparql, libtracker-miner,
libtracker-control and the tracker CLI tool.
- wip/split/miner-fs : contains everything around FS miner,
tracker-miner-fs, tracker-extract and tracker-writeback.
wip/split/rss: contains tracker-miner-rss only.

The three branches pass distcheck and build stuff into separate
tarballs, so (with some rebasing) they're a suitable starting point
for standalone repos.

Now, the bad news, things are broken, unmaintained or IMHO should be deleted:

- tracker-preferences: I'm a bit opinionated on this one,
tracker-preferences is a mixed bag of store and miner-fs
configuration, and having a GUI to configure a daemon is too 2000's
(not just the UI itself...). I think some of its functionality could
be moved to the tracker CLI tool, or just be left to DE integration
(like gnome search preferences).

- tracker-needle: This is barely maintained, IMHO we're beyond the
times that we needed a standalone/demo GUI, other apps out there make
a better work at making Tracker look nice. That said, I know other
people saw this useful, so if anyone is willing to maintain it, I'd
gladly set up other branch/repo for it.

- tracker-miner-apps: AFAIK this is unused since the maemo times, I'd
say to send it to the chopper, unless anyone wants to resuscitate it.

- tracker-miner-user-guides: ditto.

- evolution plugin/miner: it's been broken for ages. Again, if anyone
cares enough to pick this up and fix it...

- firefox and thunderbird plugins: They are basically unmaintained,
and AFAIR thunderbird was even blacklisted due to stability issues.

- nautilus tagging extension: Another one I have a hard time caring...
If this feature is as desirable, should be implemented in nautilus
itself (and most likely with better looking and more integrated
results). I'll probably split it, make a release, and never revisit
again. As above, maintainers welcome.

If anyone feels like adopting one of these items, please reply or come
over to #tracker. Speak soon or be ready to rescue a bunch of code
from git history :).

So the split seemed quite painless (the cuts were mostly clear thanks
to earlier refactors), although I'm sure that some closer analysis
will reveal more stuff to remove on each repo (esp. libtracker-common
seems like a good candidate).

The only oddity I see is that the tracker CLI tool (residing in the
core) pokes virtually everywhere, it would be nicer to make the
"tracker" command a shallow interface to subcommands, that are
installed by either tracker core, miner-fs, or whatever.

In the future, we would want the ontology out of Tracker core, but
probably at the time we can claim tracker-store is a generic SPARQL
endpoint :)

Comments? Maintainers? I won't rush this much, but would certainly
want to tackle this before the branches become too hard to
rebase/merge.

Cheers,
   Carlos
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] The Big Rip

[Philip Van Hoof]

Most of this sounds good to me Carlos. I'll reply inline


On Fri, 2016-10-28 at 14:34 +0200, Carlos Garnacho wrote:
> Hi all,
> 
> It is well known that Tracker has been accumulating lots of code and
> features over the years, with greatly varying states of maintenance.
> There's been earlier talks in this ML about splitting the whole thing
> into more palatable chunks, some refactoring happened towards making
> this easier, but it was never accomplished.
> 
> So I'd say now is just as a good time as any to finally do this, I've
> pushed (so far) the following WIP branches I worked on the last couple
> of evenings:
> 
> - wip/split/core : contains Tracker "core", most notably
> tracker-store, ontologies, libtracker-sparql, libtracker-miner,
> libtracker-control and the tracker CLI tool.

I would move libtracker-miner and libtracker-control to miner-fs or
create a wip/split/miner and move them there.

> - wip/split/miner-fs : contains everything around FS miner,
> tracker-miner-fs, tracker-extract and tracker-writeback.

Sounds good. Perhaps there are users of libracker-extract and
tracker-extract without miner-fs? In that case those could also be moved
to a separate tarball. But if everybody uses tracker-extract together
with miner-fs, then they belong together.

> wip/split/rss: contains tracker-miner-rss only.

Nobody has adopted this one yet? Damn ..

> The three branches pass distcheck and build stuff into separate
> tarballs, so (with some rebasing) they're a suitable starting point
> for standalone repos.

Cool

> Now, the bad news, things are broken, unmaintained or IMHO should be deleted:
> 
> - tracker-preferences: I'm a bit opinionated on this one,
> tracker-preferences is a mixed bag of store and miner-fs
> configuration, and having a GUI to configure a daemon is too 2000's
> (not just the UI itself...). I think some of its functionality could
> be moved to the tracker CLI tool, or just be left to DE integration
> (like gnome search preferences).

We could turn it into a libtracker-preferences-ui and a
libtracker-preferences maybe? But if it's too simple to develop this for
the DE integrators, then yeah .. just toss it in the fire.

> - tracker-needle: This is barely maintained, IMHO we're beyond the
> times that we needed a standalone/demo GUI, other apps out there make
> a better work at making Tracker look nice. That said, I know other
> people saw this useful, so if anyone is willing to maintain it, I'd
> gladly set up other branch/repo for it.

nod

> - tracker-miner-apps: AFAIK this is unused since the maemo times, I'd
> say to send it to the chopper, unless anyone wants to resuscitate it.

This doesn't work with generic .desktop files?

> - tracker-miner-user-guides: ditto.

How is or was this one different to the .txt and .doc, .pdf, etc
extractors?

> - evolution plugin/miner: it's been broken for ages. Again, if anyone
> cares enough to pick this up and fix it...

This should be maintained by the Evolution team in my opinion. But then
they have to be willing to pick it up.

> - firefox and thunderbird plugins: They are basically unmaintained,
> and AFAIR thunderbird was even blacklisted due to stability issues.

Same. s/evolution/thunderbird

> - nautilus tagging extension: Another one I have a hard time caring...
> If this feature is as desirable, should be implemented in nautilus
> itself (and most likely with better looking and more integrated
> results). I'll probably split it, make a release, and never revisit
> again. As above, maintainers welcome.

Same. s/evolution/nautilus

> If anyone feels like adopting one of these items, please reply or come
> over to #tracker. Speak soon or be ready to rescue a bunch of code
> from git history :).


> So the split seemed quite painless (the cuts were mostly clear thanks
> to earlier refactors), although I'm sure that some closer analysis
> will reveal more stuff to remove on each repo (esp. libtracker-common
> seems like a good candidate).

Or just move code that isn't reused by +1 component to the component.

> The only oddity I see is that the tracker CLI tool (residing in the
> core) pokes virtually everywhere, it would be nicer to make the
> "tracker" command a shallow interface to subcommands, that are
> installed by either tracker core, miner-fs, or whatever.

nod. Good idea

> In the future, we would want the ontology out of Tracker core, but
> probably at the time we can claim tracker-store is a generic SPARQL
> endpoint :)

yep

> Comments? Maintainers? I won't rush this much, but would certainly
> want to tackle this before the branches become too hard to
> rebase/merge.

Can each new repository be a clone of the full original one, and then
remove from the clone until all unneeded files are gone? That way we
keep the version and commit history.

Kind regards,

Philip



signature.asc
Description: This is a digitally signed message part
___
tracker-list mailing list

Re: [Tracker] The Big Rip

[Sam Thursfield]

Hi!

On 10/28/16, Carlos Garnacho  wrote:
> It is well known that Tracker has been accumulating lots of code and
> features over the years, with greatly varying states of maintenance.
> There's been earlier talks in this ML about splitting the whole thing
> into more palatable chunks, some refactoring happened towards making
> this easier, but it was never accomplished.
>
> So I'd say now is just as a good time as any to finally do this, I've
> pushed (so far) the following WIP branches I worked on the last couple
> of evenings:
>
> - wip/split/core : contains Tracker "core", most notably
> tracker-store, ontologies, libtracker-sparql, libtracker-miner,
> libtracker-control and the tracker CLI tool.
> - wip/split/miner-fs : contains everything around FS miner,
> tracker-miner-fs, tracker-extract and tracker-writeback.
> wip/split/rss: contains tracker-miner-rss only.
>
> The three branches pass distcheck and build stuff into separate
> tarballs, so (with some rebasing) they're a suitable starting point
> for standalone repos.

I think we need to be careful about doing this in a way that's useful
for everyone, and only dong it if there's a good reason. So it would
be great if some Tracker users & packagers could comment here.

It might be worth cc'ing the distributor-list to get wider feedback.

What are the use cases of the separated tracker-core and
tracker-miner-fs repos? I mean, in what situations will someone want
to use one without the other?

> Now, the bad news, things are broken, unmaintained or IMHO should be
> deleted:
>
> - tracker-preferences: I'm a bit opinionated on this one,
> tracker-preferences is a mixed bag of store and miner-fs
> configuration, and having a GUI to configure a daemon is too 2000's
> (not just the UI itself...). I think some of its functionality could
> be moved to the tracker CLI tool, or just be left to DE integration
> (like gnome search preferences).

It should really be left to desktop environment configuration, indeed...

The existing code is no doubt a good starting point for a
gnome-control-centre panel. Perhaps we should have some kind of
tracker-example-apps repo for the existing preferences code?

It's basically all miner-fs config, I don't see any store
configuration options there (which seems correct, there's nothing
useful for end-users to configure about the store).

> - tracker-needle: This is barely maintained, IMHO we're beyond the
> times that we needed a standalone/demo GUI, other apps out there make
> a better work at making Tracker look nice. That said, I know other
> people saw this useful, so if anyone is willing to maintain it, I'd
> gladly set up other branch/repo for it.

Again, move to a tracker-example-apps repo?

> - tracker-miner-apps: AFAIK this is unused since the maemo times, I'd
> say to send it to the chopper, unless anyone wants to resuscitate it.
>
> - tracker-miner-user-guides: ditto.

Maybe the Jolla folk are still using this? If so maybe they could
adopt them? They're not useful in GNOME to my knowledge.

> - evolution plugin/miner: it's been broken for ages. Again, if anyone
> cares enough to pick this up and fix it...
>
> - firefox and thunderbird plugins: They are basically unmaintained,
> and AFAIR thunderbird was even blacklisted due to stability issues.

> - nautilus tagging extension: Another one I have a hard time caring...
> If this feature is as desirable, should be implemented in nautilus
> itself (and most likely with better looking and more integrated
> results). I'll probably split it, make a release, and never revisit
> again. As above, maintainers welcome.

Seems fair, these are definitely not getting enough maintenance to be
considered part of 'core' tracker.

...

> The only oddity I see is that the tracker CLI tool (residing in the
> core) pokes virtually everywhere, it would be nicer to make the
> "tracker" command a shallow interface to subcommands, that are
> installed by either tracker core, miner-fs, or whatever.

I spotted that;

> In the future, we would want the ontology out of Tracker core, but
> probably at the time we can claim tracker-store is a generic SPARQL
> endpoint :)
>
> Comments? Maintainers? I won't rush this much, but would certainly
> want to tackle this before the branches become too hard to
> rebase/merge.

I don't really have the desire to become a maintainer, but at the same
time it seems like you have to do everything right now so I am willing
to step up my involvement a bit... perhaps I could take on one of the
repos.

Sam
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] The Big Rip

[Carlos Garnacho]

Hi all,

It is well known that Tracker has been accumulating lots of code and
features over the years, with greatly varying states of maintenance.
There's been earlier talks in this ML about splitting the whole thing
into more palatable chunks, some refactoring happened towards making
this easier, but it was never accomplished.

So I'd say now is just as a good time as any to finally do this, I've
pushed (so far) the following WIP branches I worked on the last couple
of evenings:

- wip/split/core : contains Tracker "core", most notably
tracker-store, ontologies, libtracker-sparql, libtracker-miner,
libtracker-control and the tracker CLI tool.
- wip/split/miner-fs : contains everything around FS miner,
tracker-miner-fs, tracker-extract and tracker-writeback.
wip/split/rss: contains tracker-miner-rss only.

The three branches pass distcheck and build stuff into separate
tarballs, so (with some rebasing) they're a suitable starting point
for standalone repos.

Now, the bad news, things are broken, unmaintained or IMHO should be deleted:

- tracker-preferences: I'm a bit opinionated on this one,
tracker-preferences is a mixed bag of store and miner-fs
configuration, and having a GUI to configure a daemon is too 2000's
(not just the UI itself...). I think some of its functionality could
be moved to the tracker CLI tool, or just be left to DE integration
(like gnome search preferences).

- tracker-needle: This is barely maintained, IMHO we're beyond the
times that we needed a standalone/demo GUI, other apps out there make
a better work at making Tracker look nice. That said, I know other
people saw this useful, so if anyone is willing to maintain it, I'd
gladly set up other branch/repo for it.

- tracker-miner-apps: AFAIK this is unused since the maemo times, I'd
say to send it to the chopper, unless anyone wants to resuscitate it.

- tracker-miner-user-guides: ditto.

- evolution plugin/miner: it's been broken for ages. Again, if anyone
cares enough to pick this up and fix it...

- firefox and thunderbird plugins: They are basically unmaintained,
and AFAIR thunderbird was even blacklisted due to stability issues.

- nautilus tagging extension: Another one I have a hard time caring...
If this feature is as desirable, should be implemented in nautilus
itself (and most likely with better looking and more integrated
results). I'll probably split it, make a release, and never revisit
again. As above, maintainers welcome.

If anyone feels like adopting one of these items, please reply or come
over to #tracker. Speak soon or be ready to rescue a bunch of code
from git history :).

So the split seemed quite painless (the cuts were mostly clear thanks
to earlier refactors), although I'm sure that some closer analysis
will reveal more stuff to remove on each repo (esp. libtracker-common
seems like a good candidate).

The only oddity I see is that the tracker CLI tool (residing in the
core) pokes virtually everywhere, it would be nicer to make the
"tracker" command a shallow interface to subcommands, that are
installed by either tracker core, miner-fs, or whatever.

In the future, we would want the ontology out of Tracker core, but
probably at the time we can claim tracker-store is a generic SPARQL
endpoint :)

Comments? Maintainers? I won't rush this much, but would certainly
want to tackle this before the branches become too hard to
rebase/merge.

Cheers,
  Carlos
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list