Re: [Tracker] Roadmap to 0.7

[Martyn Russell <martyn lanedo com>]

On 12/07/09 13:11, Ivan Frade wrote:
> Hi,

Hi,

>   Thinking about the future of tracker-search-tool (understand t-s-t as
> a end-user program), i see only 4 options:
>
> a) Kill tracker-search-tool. Focus on the daemon, and let external apps
> be our UI.

This is not a good idea. People expect some sort of UI to show off what 
you can do with Tracker. Without this people quickly loose interest when 
trying the project out. Not to mention, if we have a UI, we have a tool 
to test our engine with.

The importance of this should not be underestimated at all :)

> b) Quick fix the current t-s-t (modify the code to use sparql and some
> dirty hacks to keep everything similar).

Well, I would remove the directory and create something new with a new 
name too.

Jamie I would also do this in another branch so we can review it before 
merging to master.

> c) Rewrite t-s-t (probably in a different language) with the same UI.

I personally would elect for Vala since we already use that. I haven't 
seen what Genie is like though so...

I definitely wouldn't do it in C though - might even make sense to use 
Pygtk because it will be fast and demonstrate language compatibility.

> d) Write a brand new t-s-t with a brand new UI that shows how powerful
> is the daemon.

Well, as I put on the current roadmap, there is currently NO way to 
control Tracker in 0.7 from the UI. The DBus API we have right now has 
no control at all. Carlos and I want to work on a base class for each 
miner so we can list them all in an applet or UI and be able to control 
them and see the progress of each of them. This would also allow the 
user to pause all or specific miners.

>   We have also three "milestones" in tracker in the near future:
>
> 1) 0.7.0 release

Right. I want to get this done in the next month or so. I am not sure 
exactly how quickly Jamie can do the UI, but it all hinges on him I 
think. We should have the other parts done by the time the UI is ready.

I would also like to update the website for the release so we have a new 
look there too! People didn't know there was one from my impression at 
the summit.

> 2) 0.7.x cycle

Once a month is my suggestion - as a minimum too.

> 3) for the stable 0.8 release

As an additional note here, speaking to Bastien at the summit, he 
recommended we get Tracker into GNOME and release with those schedules 
so we align ourselves with other distros (Ubuntu/Fedora/etc). I think 
this makes sense.

Any views on that?

>   So, we can combine different decisions and moments (E.g. quick hack
> for 0.7.0 and new UI for 0.8) (or in chess notation: b1, d3).

Yea, I don't think that will work. As stated above, as soon as you 
announce something, if the user has nothing to try other than a bunch of 
command line utils, they won't be impressed. It is better to have 
something (even if it is simple and fast) than nothing visually.

>   My opinion: At some point we should get rid of t-s-t (or revamp it
> into a developer tool). With the new architecture, tracker is not a user
> program anymore, but an efficient backend for applications.

Well, that sounds pretty much like what tracker-explorer is. We already 
have that in the tree so we should just build on that IMO.

>   0.7.x are development releases, not intended for distribution (i.e.
> end-users), and we want a release ASAP because some applications are
> interested in testing it. So i prefer to focus in _documentation_ and
> stability than waste time on the UI. To remove t-s-t in 0.7.0 or to fix
> it quickly to release soon is fine with me. We can add it again later if
> necessary.

Well, applications can still checkout unreleased master if they want to 
get a feel for Tracker. Releasing is about us saying we are ready not 
about doing it for applications.

The UI won't take long and it will be a tool to test the engine anyway 
just like your GLib unit tests are.

--
Regards,
Martyn