Re: New module proposal: tracker
On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote: Hi all, So we recently polled the tracker mailing list to make sure the core developers and others interested had an opinion on GNOME module inclusion for Tracker. You can see the thread here: http://mail.gnome.org/archives/tracker-list/2009-August/msg7.html The response was positive. So I would like to propose Tracker as a new GNOME module. [mime] Isn't tracker a cross-desktop (freedesktop) project? Or don't KDE want to use it? Could making it an official GNOME project make it less likely to be used by non-GNOME applications? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project proposal: libvtemm
On Tue, 2009-10-27 at 00:20 +0100, Murray Cumming wrote: On Tue, 2009-10-27 at 00:08 +0100, Andre Klapper wrote: Am Montag, den 12.10.2009, 17:35 +0200 schrieb Krzesimir Nowak: I'm a maintainer of libvtemm and I'd like to propose it to be a part of GNOME. Libraries don't belong in Desktop until they are used by something in Desktop. There was nothing about it in Specific Requirements for each Release Set [1]. But if this is true then there is no sense in forcing this proposal. [1] http://live.gnome.org/ReleasePlanning/ModuleRequirements Libraries don't belong in Platform Bindings unless they wrap something in the Platform. There's no question of this going into the Platform. Maybe the maintainer misunderstands the purpose of the release sets. Its not just a stamp of officialness. The rest of GNOME's infrastructure is available without being in a release set and a library will then be used if it is useful to developers. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Wed, 2009-10-28 at 20:04 -0700, Sriram Ramkrishna wrote: I think I'm with Zeeshan here. It looks like you should have some time to get some real world testing before putting it into the release. Do you guys have objection to that? Correct me if I am wrong, but isn't tracker 0.7 being shipped in maemo 5? That seems like a pretty significant real world test case. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Am Mittwoch, den 28.10.2009, 20:04 -0700 schrieb Sriram Ramkrishna: So the current barriers I see is: [...] * release process should match with GNOME. As I see regular (weekly) releases at ftp://ftp.gnome.org/pub/GNOME/sources/tracker/0.7/ I don't see an issue at all with regard to that point. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 10:27 +0100, John Stowers wrote: Correct me if I am wrong, but isn't tracker 0.7 being shipped in maemo 5? That seems like a pretty significant real world test case. Nopes. Maemo 5 comes with Tracker 0.6.95 J.A. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 10:44 +0100, Andre Klapper wrote: Am Mittwoch, den 28.10.2009, 20:04 -0700 schrieb Sriram Ramkrishna: So the current barriers I see is: [...] * release process should match with GNOME. As I see regular (weekly) releases at ftp://ftp.gnome.org/pub/GNOME/sources/tracker/0.7/ I don't see an issue at all with regard to that point. But what about API freezes, for instance, and other freezes? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Am Donnerstag, den 29.10.2009, 11:57 +0100 schrieb Murray Cumming: On Thu, 2009-10-29 at 10:44 +0100, Andre Klapper wrote: Am Mittwoch, den 28.10.2009, 20:04 -0700 schrieb Sriram Ramkrishna: So the current barriers I see is: [...] * release process should match with GNOME. As I see regular (weekly) releases at ftp://ftp.gnome.org/pub/GNOME/sources/tracker/0.7/ I don't see an issue at all with regard to that point. But what about API freezes, for instance, and other freezes? Of course that's a must, but so far I don't expect proposed modules to follow that before even being proposed. ;-) Freezes for 2.29.x are listed at http://live.gnome.org/Schedule http://live.gnome.org/TwoPointTwentynine and every approved app must follow these - same for tracker after a potential inclusion and I expect tracker maintainers to be totally aware of this. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On 29/10/09 03:04, Sriram Ramkrishna wrote: I think I'm with Zeeshan here. It looks like you should have some time to get some real world testing before putting it into the release. Do you guys have objection to that? Regarding real-world testing, yes, I think you're right. We are expecting to be in good shape by the end of the year for the 0.8 releases. So the current barriers I see is: * relative newness of the api - will it change further? You guys should have some stability It is quite unlikely. The APIs haven't changed recently. I say that, we just noticed something in libtracker-miner that needs improving (sync/async issue). But generally, the API doesn't need improving any further. There may be some additions to the libtracker-miner API as we integrate web application support (such as Facebook, etc). * release process should match with GNOME. Yes, it should. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On 29/10/09 09:27, John Stowers wrote: On Wed, 2009-10-28 at 20:04 -0700, Sriram Ramkrishna wrote: I think I'm with Zeeshan here. It looks like you should have some time to get some real world testing before putting it into the release. Do you guys have objection to that? Correct me if I am wrong, but isn't tracker 0.7 being shipped in maemo 5? That seems like a pretty significant real world test case. No. 0.6 is. A lot of those fixes are of course folded back to upstream. Harmattan is using Tracker of course and much more heavily, this is why we are constantly finding bugs to fix and ontologies to improve on. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On 29/10/09 11:08, Andre Klapper wrote: Am Donnerstag, den 29.10.2009, 11:57 +0100 schrieb Murray Cumming: On Thu, 2009-10-29 at 10:44 +0100, Andre Klapper wrote: Am Mittwoch, den 28.10.2009, 20:04 -0700 schrieb Sriram Ramkrishna: So the current barriers I see is: [...] * release process should match with GNOME. As I see regular (weekly) releases at ftp://ftp.gnome.org/pub/GNOME/sources/tracker/0.7/ I don't see an issue at all with regard to that point. But what about API freezes, for instance, and other freezes? Of course that's a must, but so far I don't expect proposed modules to follow that before even being proposed. ;-) Freezes for 2.29.x are listed at http://live.gnome.org/Schedule; http://live.gnome.org/TwoPointTwentynine and every approved app must follow these - same for tracker after a potential inclusion and I expect tracker maintainers to be totally aware of this. Yes and I agree with everything you said here. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Hi, On Thu, Oct 29, 2009 at 1:05 PM, Martyn Russell mar...@lanedo.com wrote: On 28/10/09 23:23, Zeeshan Ali (Khattak) wrote: I think assuming that a project has to be shipped by distros before it can be in GNOME or visa versa doesn't make sense. Distros ALWAYS ship what they want and they want something stable. 0.6 is the last stable version we have and 0.7. Distros do ship what they want but there is a predictable pattern to their desires. :) What about maemo? N900 will continue to ship with 0.6 and if i want my app to work on N900, i'll need to keep on dealing with 0.6 for quite some time in future. Correct me if i am wrong but 0.7 release happened fairly recently, no? Its been quite some time that I've been dealing with crappy 0.6 APIs so as an application developer I (and others) would need some time to evaluate 0.7 APIs if they really are as perfect as you claim or not. Working with 0.6 I've known nothing but pain (leaving aside all the political pressure I've been facing for making my app so dependent on Tracker) so please understand that I need some time to be sure that 0.7 is completely different in that regard. Until then, I am skeptical about Tracker to become integral part of GNOME. Also I share the concern of Lennart about inotify limitation and from my talks with Tracker developers so far, it seems they underestimate the importance of fixing this limitation wrt Tracker. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 P.S. These mails are written as a GNOME/Maemo developer rather than a Nokia employee since I am not really officially involved in Fremantle/N900 anymore. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
seahorse-plugins branched for 2.28
seahorse-plugins has branched for 2.28 (gnome-2-28). Development continues on master. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On 29/10/09 15:23, Zeeshan Ali (Khattak) wrote: Hi, On Thu, Oct 29, 2009 at 1:05 PM, Martyn Russellmar...@lanedo.com wrote: On 28/10/09 23:23, Zeeshan Ali (Khattak) wrote: I think assuming that a project has to be shipped by distros before it can be in GNOME or visa versa doesn't make sense. Distros ALWAYS ship what they want and they want something stable. 0.6 is the last stable version we have and 0.7. Distros do ship what they want but there is a predictable pattern to their desires. :) What about maemo? N900 will continue to ship with 0.6 and if i want my app to work on N900, i'll need to keep on dealing with 0.6 for quite some time in future. There are talks of upgrading it on the n900. Nothing more than that right now. Correct me if i am wrong but 0.7 release happened fairly recently, no? Yes, sorry that was a typo, s/and 0.7//. Its been quite some time that I've been dealing with crappy 0.6 APIs so as an application developer I (and others) would need some time to evaluate 0.7 APIs if they really are as perfect as you claim or not. The APIs in 0.7 are diminished since 0.6 because we use SPARQL to query/update the databases. The benefit of this is that the dbus/library APIs don't change. The only exception here is the libtracker-miner API which is a new addition and still being improved on in areas. But that's more for applications wanting to insert data not query it. The SPARQL we use changes at times too (if you consider that API) but usually to fix or add features that didn't exist before. To give you an example, we are considering adding a coalesce function for when data doesn't exist to have a default or fallback value. This would mean you could use the following SPARQL: SELECT COALESCE(nie:title(?n), nfo:fileName(?n), unknown) This means, (in the case where a video file has no title metadata, the title would be used if available and fallback to the file name if it wasn't. Of course, if the file name is not available then unknown would be used as a last resort. This function doesn't exist yet in Tracker, but to add it just means you get more flexibility in your query language. There is no library or DBus API that changes here. Working with 0.6 I've known nothing but pain (leaving aside all the political pressure I've been facing for making my app so dependent on Tracker) so please understand that I need some time to be sure that 0.7 is completely different in that regard. Until then, I am skeptical about Tracker to become integral part of GNOME. I hear the same thing over and over again from people that used 0.6. Carlos and I have spent 2 years refactoring and redesigning the *ENTIRE* code base. Not only that Jürg and Philip have also been doing the same since they came on the project (Philip in April 2008 and Jürg in November 2008). Helping in this have also been Ivan Frade and Mikael Ottela (at Nokia) since the project was taken on for the Maemo 5 platform. During the time that Carlos, Mikael, Ivan and I have been fixing 0.6.x issues for the Maemo platform, Philip and Jürg started working on 0.7. which drastically changed the design and communication between all major parts of Tracker. This came after a lot of review and discussion by the core team. Comparing 0.6. to 0.7. is folly, they are so different and any project would be after 2 years of full time coding from 6 people and public contributions on top of that. Also I share the concern of Lennart about inotify limitation and from my talks with Tracker developers so far, it seems they underestimate the importance of fixing this limitation wrt Tracker. I agree it needs fixing, but there are a number of things to consider here: - FANotify is being worked on by Red Hat and will be in the kernel for us to use at some point - and we will adopt it then (I believe it almost made it into the latest Fedora but didn't so should be in the next release) - We changed the locations that are indexed by default from $HOME to use XDG user dirs for documents, desktop, music, pictures and videos. So the focus has changed slightly to the things you most likely want indexed instead of EVERYTHING. Of course adding EVERYTHING into the config doesn't escape the fact that inotify is limiting us. - In the grand scheme of things, I don't think it is that important to fix as Lennart says. I don't consider myself a normal user and I don't even breach the inotify limit (I come close though with all the project sources monitored). I personally would much rather have an Tracker which is fast to query/update and has good coverage on the metadata it extracts as a priority over supporting EXTREME use cases. I do want this fixed but it has not been our focus because we have had so many other issues to contend with first which were much more important. -- Regards, Martyn ___ desktop-devel-list mailing list
Re: New module proposal: tracker
On do, 2009-10-29 at 17:21 +, Martyn Russell wrote: Working with 0.6 I've known nothing but pain (leaving aside all the political pressure I've been facing for making my app so dependent on Tracker) so please understand that I need some time to be sure that 0.7 is completely different in that regard. Until then, I am skeptical about Tracker to become integral part of GNOME. I hear the same thing over and over again from people that used 0.6. Carlos and I have spent 2 years refactoring and redesigning the *ENTIRE* code base. Not only that Jürg and Philip have also been doing the same since they came on the project (Philip in April 2008 and Jürg in November 2008). Helping in this have also been Ivan Frade and Mikael Ottela (at Nokia) since the project was taken on for the Maemo 5 platform. During the time that Carlos, Mikael, Ivan and I have been fixing 0.6.x issues for the Maemo platform, Philip and Jürg started working on 0.7. which drastically changed the design and communication between all major parts of Tracker. This came after a lot of review and discussion by the core team. Comparing 0.6. to 0.7. is folly, they are so different and any project would be after 2 years of full time coding from 6 people and public contributions on top of that. From a devil's advocate point of view: this might just mean that it got worse (though I doubt it). Zeeshan raises concerns and while you go to great lengths to explain that it is different, there is nothing that might convince him that it is actually *better*. Also I share the concern of Lennart about inotify limitation and from my talks with Tracker developers so far, it seems they underestimate the importance of fixing this limitation wrt Tracker. I agree it needs fixing, but there are a number of things to consider here: - FANotify is being worked on by Red Hat and will be in the kernel for us to use at some point - and we will adopt it then (I believe it almost made it into the latest Fedora but didn't so should be in the next release) - We changed the locations that are indexed by default from $HOME to use XDG user dirs for documents, desktop, music, pictures and videos. So the focus has changed slightly to the things you most likely want indexed instead of EVERYTHING. Of course adding EVERYTHING into the config doesn't escape the fact that inotify is limiting us. - In the grand scheme of things, I don't think it is that important to fix as Lennart says. I don't consider myself a normal user and I don't even breach the inotify limit (I come close though with all the project sources monitored). I personally would much rather have an Tracker which is fast to query/update and has good coverage on the metadata it extracts as a priority over supporting EXTREME use cases. I do want this fixed but it has not been our focus because we have had so many other issues to contend with first which were much more important. Erm, wouldn't the lack of a recursive notification mechanism imply that you have to do a directory crawl at startup to place notify watches on each and every file? That *is* an important issue, much more than the potential of running into the limits in, as you said, extreme cases. Hugely occupying the hard disk when the user wants to start using his/her computer is bad. And please don't say low priority I/O, disk seeks take time, so even when the priority is low, other apps will be affected by it. So the question is: does the indexer do a full directory crawl when starting? Because in that case, I don't want it. So not having recursive inotify (or something alike) can be a problem for the indexer. Which does not say much about the data store. I think it might be wise to consider the tracker data store and the tracker indexer as separate components to propose, given the different issues involved. R -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On 29/10/09 18:20, Ruben Vermeersch wrote: On do, 2009-10-29 at 17:21 +, Martyn Russell wrote: From a devil's advocate point of view: this might just mean that it got worse (though I doubt it). Zeeshan raises concerns and while you go to great lengths to explain that it is different, there is nothing that might convince him that it is actually *better*. True, but the point is, it isn't the same contrary to popular belief ;) Erm, wouldn't the lack of a recursive notification mechanism imply that you have to do a directory crawl at startup to place notify watches on each and every file? We do this per directory not per file. That *is* an important issue, much more than the potential of running into the limits in, as you said, extreme cases. Hugely occupying the hard disk when the user wants to start using his/her computer is bad. What do you mean by hugely occupying? So the question is: does the indexer do a full directory crawl when starting? Because in that case, I don't want it. Yes for now. We have considered only doing this initially but the cost for doing this (in 0.7) is cheap and the concern is more that we could miss file updates or new files. Have you tried 0.7? So not having recursive inotify (or something alike) can be a problem for the indexer. Which does not say much about the data store. I think it might be wise to consider the tracker data store and the tracker indexer as separate components to propose, given the different issues involved. This has been suggested before too. I don't believe that makes sense either but then my opinion isn't the only one :) -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Il giorno gio, 29/10/2009 alle 01.23 +0200, Zeeshan Ali (Khattak) ha scritto: IMO right now you should push on the distros to start shipping that (e.g Ubuntu Karmic still seem to have 0.6) and once distro and existing apps have competely moved to 0.7, all concerned parties will have a significant amount of trust on the tracker project and the decision to make it part of GNOME will go much smoothly in the next release. But in previous GNOME release we accepted stuff like PolicyKit or DeviceKit or PulseAudio while not yet officially released or widely adopted. And those stuff was needed to be installed under /usr in order to properly work. Tracker, instead, can be simply tested in a JHbuild sandbox. So this doesn't seem to me a reason to drop its inclusion. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 22:25 +0100, Luca Ferretti wrote: But in previous GNOME release we accepted stuff like PolicyKit or DeviceKit or PulseAudio while not yet officially released or widely adopted. And those stuff was needed to be installed under /usr in order to properly work. I believe all of these things are (optional) dependencies, not anything part of the GNOME desktop proper. Except for maybe PulseAudio. Solaris, for example, don't use any of this stuff. Tracker, instead, can be simply tested in a JHbuild sandbox. So this doesn't seem to me a reason to drop its inclusion. I'm with Zeeshan on this - what's the harm of delaying the inclusion of Tracker until it has actually proven itself to be useful for Linux Desktop uses? (In my view, Maemo isn't a typical Linux Desktop) Not to sound like an asshole or anything but, I mean, didn't distros try including Tracker by default in previous releases? AFAIR, it didn't really work well. So if GNOME included Tracker in the next release and core parts of GNOME started depending on it in a way that couldn't be turned off... then distros would be in a lot of trouble if Tracker didn't work well. This would probably end up reflecting badly on the GNOME project. Instead, I'd be a lot more thrilled if the Tracker developers would suggest Tracker as an optional dependency (just like e.g. polkit is.. or at least used to be) - e.g. apps using Tracker would have need a --disable-tracker or --enable-tracker configure option. This way we can start integrating Tracker into GNOME without causing the ride to be too bumpy. Thanks, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, Oct 29, 2009 at 3:59 PM, Martyn Russell mar...@lanedo.com wrote: On 29/10/09 22:49, Sandy Armstrong wrote: On Thu, Oct 29, 2009 at 3:06 PM, Patryk Zawadzkipat...@pld-linux.org wrote: On Thu, Oct 29, 2009 at 10:51 PM, David Zeuthenda...@fubar.dk wrote: Not to sound like an asshole or anything but, I mean, didn't distros try including Tracker by default in previous releases? AFAIR, it didn't really work well. So if GNOME included Tracker in the next release and core parts of GNOME started depending on it in a way that couldn't be turned off... then distros would be in a lot of trouble if Tracker didn't work well. This would probably end up reflecting badly on the GNOME project. Are we talking about the tracker crawler or tracker itself (index and metadata storage)? I can understand how including the crawler is not the best idea (especially until we get ourselves recursive inotify support) but what can go wrong with tracker itself? What can go wrong introducing a brand new barely-used technology and set of APIs as something we call GNOME? I think that question answers itself. ;-) I already said which applications use it. Tracker is not brand new and it is not barely used. To be clear, I was speaking about the store as opposed to the indexing. Where is it used on the desktop? The 0.7.x APIs are brand new and barely used, if I've understood this thread correctly. So the most pragmatic approach seems to be to wait until Tracker matures and people are using it in ways that make including it as part of the GNOME desktop an easy choice. Right now, we're still at the imagine the possibilities stage with Tracker on the desktop. Are we? Have you tried it yet? Looking a few dozen emails back at your list of how Tracker is currently used, everything currently implemented is related to indexing, not the store (unless you look at Maemo). Also, your list was a list of applications that somehow use or integrate with Tracker. It was not a list of use cases, and did not describe in detail how those applications are integrating with Tracker. Is it just more indexing stuff? And no, I have not tried Tracker in a long time. An indexer is not something useful to me (though I agree it is useful to many people), and the store has (at this time) nothing to offer me as a user, from what I understand. I'd rather wait until some compelling use cases are actually implemented. What use cases would you like to see? I think this is kind of the core of the problem here. I get the feeling that the Tracker developers are proposing a technology because they want to enable application developers, and that it is expected that application developers will come up with and implement compelling use cases. Like others in this thread, I think this is just backwards. I feel like the applications and use cases should shape the Tracker API, and it's in everyone's best interest not to bring it in prematurely. I'm not trying to knock Tracker at all, because I think it's cool stuff. I just would rather we bring it in when our applications are using it in ways that will provide clear benefits to our users. Right now, the only clear benefit I see is better search thanks to the indexer. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 17:51 -0400, David Zeuthen wrote: On Thu, 2009-10-29 at 22:25 +0100, Luca Ferretti wrote: But in previous GNOME release we accepted stuff like PolicyKit or DeviceKit or PulseAudio while not yet officially released or widely adopted. And those stuff was needed to be installed under /usr in order to properly work. I believe all of these things are (optional) dependencies, not anything part of the GNOME desktop proper. Except for maybe PulseAudio. Solaris, for example, don't use any of this stuff. Tracker, instead, can be simply tested in a JHbuild sandbox. So this doesn't seem to me a reason to drop its inclusion. I'm with Zeeshan on this - what's the harm of delaying the inclusion of Tracker until it has actually proven itself to be useful for Linux Desktop uses? (In my view, Maemo isn't a typical Linux Desktop) its already useful (except for maybe geeks that dont want an indexer) Not to sound like an asshole or anything but, I mean, didn't distros try including Tracker by default in previous releases? AFAIR, it didn't really work well. So if GNOME included Tracker in the next release and core parts of GNOME started depending on it in a way that couldn't be turned off... then distros would be in a lot of trouble if Tracker didn't work well. This would probably end up reflecting badly on the GNOME project. this is all hypothetical. What matters is that people actually try it out then make judgements based on whether the current tracker gives a good experience. If people dont do this then the same arguments will be made whenever tracker is proposed again regardless of how good or bad it is Instead, I'd be a lot more thrilled if the Tracker developers would suggest Tracker as an optional dependency (just like e.g. polkit is.. or at least used to be) - e.g. apps using Tracker would have need a --disable-tracker or --enable-tracker configure option. This way we can start integrating Tracker into GNOME without causing the ride to be too bumpy. all the optional use cases are pretty much already done (nautilus, file chooser, totem etc). The problem is that to leverage the full power of tracker, you need much deeper integration and its not practical to make it optional in those cases The way I see it is if Gnome wants to be in a position to challenge OS/X and Windows 7 then it needs to make bold decisions. Playing it safe means it will stagnate and Gnome will miss out on all the cool technology. jamie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
Martyn Russell : On 29/10/09 21:51, David Zeuthen wrote: On Thu, 2009-10-29 at 22:25 +0100, Luca Ferretti wrote: But in previous GNOME release we accepted stuff like PolicyKit or DeviceKit or PulseAudio while not yet officially released or widely adopted. And those stuff was needed to be installed under /usr in order to properly work. I believe all of these things are (optional) dependencies, not anything part of the GNOME desktop proper. Except for maybe PulseAudio. Solaris, for example, don't use any of this stuff. That's not true, we have a few Solaris people sending us patches from time to time. Tracker 0.6.x is already in OpenSolaris. but porting 0.7.x to solaris is not finished yet. because it changes so dramatically. Tracker, instead, can be simply tested in a JHbuild sandbox. So this doesn't seem to me a reason to drop its inclusion. I'm with Zeeshan on this - what's the harm of delaying the inclusion of Tracker until it has actually proven itself to be useful for Linux Desktop uses? (In my view, Maemo isn't a typical Linux Desktop) Maemo is a target platform being used by real people just like the desktop is so I don't agree with that argument. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 22:49 +, Martyn Russell wrote: I believe all of these things are (optional) dependencies, not anything part of the GNOME desktop proper. Except for maybe PulseAudio. Solaris, for example, don't use any of this stuff. That's not true, we have a few Solaris people sending us patches from time to time. I think you misunderstood what I said. I wasn't talking about Tracker. And it's good that the Solaris people are sending you patches. The point, really, is that Luca was incorrect in stating that we (GNOME) unconditionally adopts dependencies that are not widely deployed or fully baked. This was true (and in a sense, still is for some of these components) for polkit, devkit-disks/gnome-disk-utility, Pulseaudio, PackageKit and the list goes on. Why do you think it should it be any different for Tracker? I'm with Zeeshan on this - what's the harm of delaying the inclusion of Tracker until it has actually proven itself to be useful for Linux Desktop uses? (In my view, Maemo isn't a typical Linux Desktop) Maemo is a target platform being used by real people just like the desktop is Of course it is, no one is disputing that. so I don't agree with that argument. Here's the point: Surely, Maemo, or, rather, Nokia (who develops the bulk of Maemo) went through the motions of working out why Tracker is useful and, you know, actually, patched their set of apps to use it. Including spending a lot of money making all this happen. All I'm saying is that we need to do the same in GNOME. This is double-plus true because GNOME has a much more diverse set of downstreams. In other words, there are many products (distros if you like) that incorporate GNOME. Consequently, because GNOME is a lot of things to a lot of people it's much *harder* to figure out how to use and deploy Tracker in a meaningful way. I think the recent threads about Tracker and GNOME really shows this. Anyway, I'm really not so sure why it's so important for you guys to be in the GNOME Desktop right away. Again, I'd much rather see Tracker as a blessed optional dependency (ideally following the GNOME release schedules) while you work with applications authors so they can use Tracker to deliver great value and all that good stuff. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 19:38 -0400, Jamie McCracken wrote: this is all hypothetical. What matters is that people actually try it out then make judgements based on whether the current tracker gives a good experience. If people dont do this then the same arguments will be made whenever tracker is proposed again regardless of how good or bad it is Sure. This means you need to lobby the distributions to ensure that Tracker is installed by default. That's what a lot of people are saying here - you need to make sure people feel all warm and fuzzy before you can make them accept a non-optional dependency. The problem is that to leverage the full power of tracker, you need much deeper integration and its not practical to make it optional in those cases This is a very general and broad statement concerning the key element in this discussion. I think it would help your case if you expanded on why this is so and what power would be unleashed. The way I see it is if Gnome wants to be in a position to challenge OS/X and Windows 7 then it needs to make bold decisions. Playing it safe means it will stagnate and Gnome will miss out on all the cool technology. This is kinda hyperbole - not really useful. But, hey, did you know that monitor hotplug in GNOME almost works as well as in Windows 95 now? - That is, if your video driver works with your hardware ;-) (With apologies to the X hackers. The point here, really, is that we have the work cut out for us. Indexing/metadata is important but, uh, there's so much other work that needs to be done too.) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, 2009-10-29 at 23:13 -0400, David Zeuthen wrote: On Thu, 2009-10-29 at 19:38 -0400, Jamie McCracken wrote: this is all hypothetical. What matters is that people actually try it out then make judgements based on whether the current tracker gives a good experience. If people dont do this then the same arguments will be made whenever tracker is proposed again regardless of how good or bad it is Sure. This means you need to lobby the distributions to ensure that Tracker is installed by default. That's what a lot of people are saying here - you need to make sure people feel all warm and fuzzy before you can make them accept a non-optional dependency. Whilst that is indeed one option it also is not necessary. It should not be hard for more gnome devs to try it out now like they will do for most of the other proposed apps that are not on be default in distros and then make a judgement The problem is that to leverage the full power of tracker, you need much deeper integration and its not practical to make it optional in those cases This is a very general and broad statement concerning the key element in this discussion. I think it would help your case if you expanded on why this is so and what power would be unleashed. I already did so in reply to lennart a few months back - I will not repeat myself and am sure you can find it yourself. The way I see it is if Gnome wants to be in a position to challenge OS/X and Windows 7 then it needs to make bold decisions. Playing it safe means it will stagnate and Gnome will miss out on all the cool technology. This is kinda hyperbole - not really useful. But, hey, did you know that monitor hotplug in GNOME almost works as well as in Windows 95 now? - That is, if your video driver works with your hardware ;-) Its not hyperbole - if gnome is not going to modernise I have little option but to create my own desktop to get a modern sleek desktop. (With apologies to the X hackers. The point here, really, is that we have the work cut out for us. Indexing/metadata is important but, uh, there's so much other work that needs to be done too.) I do appreciate that some geeks are not interested in tracker but hey Gnome is for the masses and search/metadata is so important especially when they have it on the web. Not having it on the desktop makes Gnome hopelessly outdated compared to modern offerings. I trust the release team will bear this in mind jamie ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
