New module proposal: tracker

[Martyn Russell-4]

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/msg00007.html

The response was positive. So I would like to propose Tracker as a new
GNOME module.

Right now Tracker 0.7 is currently in development and we are hoping to
get the 0.7. unstable release out the door in the coming month or so.

Right now we are considering making the miners (the file system crawling
at this point) optional so it acts purely as a store if needed by ISVs.
This is not yet done in master but can be if that's a GNOME requirement.

Dependencies include:

   libxml >= 0.6
   libpng >= 1.2
   libuuid
   zlib
   dbus >= 0.60
   sqlite3 >= 3.5 (built with --enable-load-extension)
   hal >= 0.5
   vala >= 0.7.3
   pango >= 1.0.0

Beyond that, the rest of the requirements affect your extraction
ability. For example, if poppler-glib is on the platform, you can then
extract PDF files. This also depends on if streamanalyser is used or not
(which does all extraction for us and negates the needs for specific
libraries in Tracker).

Dependencies about to be dropped but still needed:

   gmime
   lex
   yacc
   libraptor

The git repository is here:

http://git.gnome.org/cgit/tracker/

We import the following libraries:

   libinotify
   rasqal

Licensing wise, those libinotify and rasqal both share the LGPL, as does
libtracker. The rest is GPLv2 or later.

/discuss ;)

--
Regards,
Martyn
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Martyn Russell-4]

On 18/08/09 13:05, Martyn Russell wrote:
> Hi all,
>

...

> Dependencies about to be dropped but still needed:
>
> gmime
> lex
> yacc
> libraptor

I forgot to add, librasqal will also be dropped soon (mentioned below).

> The git repository is here:
>
> http://git.gnome.org/cgit/tracker/
>
> We import the following libraries:
>
> libinotify
> rasqal

...

--
Regards,
Martyn
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Emmanuele Bassi]

On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:

> The response was positive. So I would like to propose Tracker as a new
> GNOME module.

though I've seen the amount of work that has been done on it, I admit
I'm still ambivalent on Tracker, and the fact that nobody has come clear
with the scope of the project yet. we keep hearing stuff like "Tracker
will host all metadata about everything, ever" but since I have
objections to that I'd rather have somebody to give a balanced overview
of what Tracker is and why applications should use it.

the fact that Tracker hasn't ever gone through the external dependencies
list is also what worries me: are we proposing a module that it's just
not being used by anything in the platform?

> Right now Tracker 0.7 is currently in development and we are hoping to
> get the 0.7. unstable release out the door in the coming month or so.
>
> Right now we are considering making the miners (the file system crawling
> at this point) optional so it acts purely as a store if needed by ISVs.
> This is not yet done in master but can be if that's a GNOME requirement.

if Tracker is proposed as a metadata extractor, is there a library or an
API that allows applications to access the metadata, or am I expected to
use raw D-Bus calls?

if Tracker is proposed as a metadata storage then are there applications
that are part of the platform that are using it?

ciao,
 Emmanuele.

--
Emmanuele Bassi,
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Luis Medinas-4]

On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:

>
>    libxml >= 0.6
>    libpng >= 1.2
>    libuuid
>    zlib
>    dbus >= 0.60
>    sqlite3 >= 3.5 (built with --enable-load-extension)
>    hal >= 0.5
>    vala >= 0.7.3
>    pango >= 1.0.0
>

Is there plans to replace HAL by GIO or devicekit ? Hal will be
deprecated soon afaik.

>
> /discuss ;)
>

Also is there any plans to integrate with more applications besides
nautilus ? i mean if it's for GNOME 3.0 it should be integrated with
zeitgeist, gnome-shell and gnome-do if it will be proposed ?

Luis


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Patryk Zawadzki]

On Tue, Aug 18, 2009 at 2:57 PM, Luis Medinas<lmedinas@...> wrote:
> On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:
>>    hal >= 0.5
> Is there plans to replace HAL by GIO or devicekit ? Hal will be
> deprecated soon afaik.

...or rather by libgudev, there is no such thing as DeviceKit :)

--
Patryk Zawadzki
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Nirbheek Chauhan-2]

On Tue, Aug 18, 2009 at 6:30 PM, Patryk Zawadzki<patrys@...> wrote:
> On Tue, Aug 18, 2009 at 2:57 PM, Luis Medinas<lmedinas@...> wrote:
>> On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:
>>>    hal >= 0.5
>> Is there plans to replace HAL by GIO or devicekit ? Hal will be
>> deprecated soon afaik.
>
> ...or rather by libgudev, there is no such thing as DeviceKit :)
>

I think he meant DeviceKit-{disks,power} (and any more to come) as
well. Not sure if Tracker would be happy with the existing gio+
DK-disks + DK-power, it may need more API added to each.


--
~Nirbheek Chauhan

GNOME Team, Gentoo
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Jürg Billeter]

On Tue, 2009-08-18 at 13:57 +0100, Luis Medinas wrote:
> Is there plans to replace HAL by GIO or devicekit ? Hal will be
> deprecated soon afaik.

Richard Hughes has already ported the battery handling of Tracker to
DeviceKit-power. It's used if available, otherwise HAL is used. The
volume handling of Tracker has not been ported to DeviceKit-disks yet,
though, so we still depend on HAL for that.

> Also is there any plans to integrate with more applications besides
> nautilus ? i mean if it's for GNOME 3.0 it should be integrated with
> zeitgeist, gnome-shell and gnome-do if it will be proposed ?

Work for integration with Zeitgeist is ongoing, some more information
about this is available in various blog posts by Seif[1].

Jürg

[1] http://seilo.geekyogre.com/

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Martyn Russell-4]

On 18/08/09 13:42, Emmanuele Bassi wrote:
> On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote:
>
>> The response was positive. So I would like to propose Tracker as a new
>> GNOME module.
>
> though I've seen the amount of work that has been done on it, I admit
> I'm still ambivalent on Tracker, and the fact that nobody has come clear
> with the scope of the project yet.

That's fair.

Scope: To take over the world :)

I am not entirely sure what you want to hear regarding the scope, the
website and Bugzilla description are quite clear to me:

"All-in-one indexer, search tool and metadata database."

and

"Tracker is a tool designed to extract information and metadata about
your personal data so that it can be searched easily and quickly."

Perhaps this needs updating slightly, but ultimately it is about storing
and querying metadata about your *personal* data as efficiently as
possible. The scope can include web applications like facebook (we have
a GSoC student with a patch working on this right now) for example.

It is also a freedesktop project so it is not just for GNOME, but also
for KDE.

So depending on what you mean by scope, I hope I answered your question
there as far as the "goal", "data" and "platforms" are concerned.

> we keep hearing stuff like "Tracker
> will host all metadata about everything, ever" but since I have
> objections to that I'd rather have somebody to give a balanced overview
> of what Tracker is and why applications should use it.

Well, first and foremost it depends on the build. It can be used for
full text searching or just metadata searching (for example). Also 0.7.
works to the Nepomuk[1] standard for ontologies. This means we not only
have methods for gathering data (called miners, like the one that crawls
the file system) but we also store the data with relationships which
describe the data in terms of entities and hierarchy.

> the fact that Tracker hasn't ever gone through the external dependencies
> list is also what worries me: are we proposing a module that it's just
> not being used by anything in the platform?

Well, our initial thought was that it should probably be in the "extras"
with GNOME given not many modules use it yet.

>> Right now Tracker 0.7 is currently in development and we are hoping to
>> get the 0.7. unstable release out the door in the coming month or so.
>>
>> Right now we are considering making the miners (the file system crawling
>> at this point) optional so it acts purely as a store if needed by ISVs.
>> This is not yet done in master but can be if that's a GNOME requirement.
>
> if Tracker is proposed as a metadata extractor, is there a library or an
> API that allows applications to access the metadata, or am I expected to
> use raw D-Bus calls?

There is tracker-sparql (a binary) and an API using libtracker (which is
quite limited at this point, but does the job). You can also use DBus calls.

> if Tracker is proposed as a metadata storage then are there applications
> that are part of the platform that are using it?

The storage is only a part of it, the querying is also very important
and has been designed for speed, for example: "List all images created
on a specific month and order by date".

Currently we are working with the Zeitgeist team on an implementation
that allows them to use Tracker as a backend. If used this means
gnome-shell will ultimately depend on Tracker as I understand it.

Also nautilus depends on Tracker, but I think with 0.7 it might need
updating, I would have to check.

[1] http://nepomuk.semanticdesktop.org/

--
Regards,
Martyn
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Lennart Poettering-5]

On Tue, 18.08.09 13:05, Martyn Russell (martyn@...) 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/msg00007.html
>
> The response was positive. So I would like to propose Tracker as a new  
> GNOME module.

Hmm. The beef I have with Tracker (and Beagle fwiw) is that they build
something on infrastructure that currently is not good enough
to sustain it: inotify. inotify is simply not suitable for recursively
watching $HOME, but Tracker tries that nonetheless. And that is a big
big failure, it should not do that.

There's something I like to call the "tracker paradox": if you have
a large data set tracker is useless because inotify doesn't scale and
the database is quickly out-of-date -- and if you have a small data
set then you don't need a search engine and hence tracker is useless
too.

As I see it the usefulness of Tracker stands or falls with the
scalablity of inotify. As long as inotify does not natively support
recursive watches tracker is not viable.

Right now installing tracker on a non-trivially sized $HOME has the
effect of taking away all inotify watches and thus making inotify
unavailable for other applications -- where they usally are more
appropriately used, such as Nautilus. And all that even without fully
working properly since if the limit of inotify handles is reached the
view tracker has on the file system will necessarily become
out-of-date quickly. Or more drastically spoken: installing Tracker on
a machine with a non-trivially sized $HOME breaks Nautilus and other
software.

And no, increasing the inotify limits is a band-aid, not a fix.

Oh and inotify is not the only area where the Linux file system layer
is not ready to sustain Tracker, it's just the most obvious. Another
thing that come to my mind is that we curently lack recursive mtimes
so that tracker could identify changes on filesystems that happened
while tracker was unable to access them (i.e. due to reboot, logout,
hot unplug).

Really guys, before pushing forward with getting this into the desktop
make sure that your infrastructure is actually suitable for what you
want to do. And right now it simply is not!

All these things are fixable. Apple has shown that one can get all
these things fixed. It's just a matter of someone sitting down and
actually fixing the kernel. But as long as that hasn't happened you
are roofing your house before you built its foundation.

As I see it Tracker is not ready for inclusion in the desktop. It
might not be entirely Tracker's fault though, it's more the kernel's
fault, but that doesn't change the conclusion.

Or in short: just f*ing fix the kernel first.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Jamie McCracken-2]

The indexer part is optional

The main part tracker-store is just a database with querying and is to
be used by zeitgeist

If the consensus is that indexer is not suitable for inclusion then the
separate tracker-store should be considered for inclusion separately

the store does not do any indexing or file monitoring nor does it cosume
significant resources

jamie

On Tue, 2009-08-18 at 17:07 +0200, Lennart Poettering wrote:

> On Tue, 18.08.09 13:05, Martyn Russell (martyn@...) 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/msg00007.html
> >
> > The response was positive. So I would like to propose Tracker as a new  
> > GNOME module.
>
> Hmm. The beef I have with Tracker (and Beagle fwiw) is that they build
> something on infrastructure that currently is not good enough
> to sustain it: inotify. inotify is simply not suitable for recursively
> watching $HOME, but Tracker tries that nonetheless. And that is a big
> big failure, it should not do that.
>
> There's something I like to call the "tracker paradox": if you have
> a large data set tracker is useless because inotify doesn't scale and
> the database is quickly out-of-date -- and if you have a small data
> set then you don't need a search engine and hence tracker is useless
> too.
>
> As I see it the usefulness of Tracker stands or falls with the
> scalablity of inotify. As long as inotify does not natively support
> recursive watches tracker is not viable.
>
> Right now installing tracker on a non-trivially sized $HOME has the
> effect of taking away all inotify watches and thus making inotify
> unavailable for other applications -- where they usally are more
> appropriately used, such as Nautilus. And all that even without fully
> working properly since if the limit of inotify handles is reached the
> view tracker has on the file system will necessarily become
> out-of-date quickly. Or more drastically spoken: installing Tracker on
> a machine with a non-trivially sized $HOME breaks Nautilus and other
> software.
>
> And no, increasing the inotify limits is a band-aid, not a fix.
>
> Oh and inotify is not the only area where the Linux file system layer
> is not ready to sustain Tracker, it's just the most obvious. Another
> thing that come to my mind is that we curently lack recursive mtimes
> so that tracker could identify changes on filesystems that happened
> while tracker was unable to access them (i.e. due to reboot, logout,
> hot unplug).
>
> Really guys, before pushing forward with getting this into the desktop
> make sure that your infrastructure is actually suitable for what you
> want to do. And right now it simply is not!
>
> All these things are fixable. Apple has shown that one can get all
> these things fixed. It's just a matter of someone sitting down and
> actually fixing the kernel. But as long as that hasn't happened you
> are roofing your house before you built its foundation.
>
> As I see it Tracker is not ready for inclusion in the desktop. It
> might not be entirely Tracker's fault though, it's more the kernel's
> fault, but that doesn't change the conclusion.
>
> Or in short: just f*ing fix the kernel first.
>
> Lennart
>

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Martyn Russell-4]

On 18/08/09 16:18, Jamie McCracken wrote:
> The indexer part is optional

Well, right now it isn't but it will be at some point sure.

> The main part tracker-store is just a database with querying and is to
> be used by zeitgeist
>
> If the consensus is that indexer is not suitable for inclusion then the
> separate tracker-store should be considered for inclusion separately

That doesn't make any sense to me either. On its own it is useless then,
at least with the file system crawler it can populate the database and
be usable.

> the store does not do any indexing or file monitoring nor does it cosume
> significant resources

This is true.

--
Regards,
Martyn
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Patryk Zawadzki]

On Tue, Aug 18, 2009 at 5:18 PM, Jamie
McCracken<jamie.mccrack@...> wrote:

> The indexer part is optional
>
> The main part tracker-store is just a database with querying and is to
> be used by zeitgeist
>
> If the consensus is that indexer is not suitable for inclusion then the
> separate tracker-store should be considered for inclusion separately
>
> the store does not do any indexing or file monitoring nor does it cosume
> significant resources

Couldn't you just make gio (or gedit or OpenOffice) notify you every
time it closes a file instead of monitoring bazillions of files? I'm
not very likely to search for files I've never opened anyway.

--
Patryk Zawadzki
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Lennart Poettering-5]

On Tue, 18.08.09 11:18, Jamie McCracken (jamie.mccrack@...) wrote:

>
> The indexer part is optional
>
> The main part tracker-store is just a database with querying and is to
> be used by zeitgeist
>
> If the consensus is that indexer is not suitable for inclusion then the
> separate tracker-store should be considered for inclusion separately
>
> the store does not do any indexing or file monitoring nor does it cosume
> significant resources

I have no idea what "tracker-store" is. Please elaborate. It sounds as
it was the database that is normally filled by the indexing data, but
what could it be good for if you rip out the indexer?

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Lennart Poettering-5]

On Tue, 18.08.09 17:20, Patryk Zawadzki (patrys@...) wrote:

>
> On Tue, Aug 18, 2009 at 5:18 PM, Jamie
> McCracken<jamie.mccrack@...> wrote:
> > The indexer part is optional
> >
> > The main part tracker-store is just a database with querying and is to
> > be used by zeitgeist
> >
> > If the consensus is that indexer is not suitable for inclusion then the
> > separate tracker-store should be considered for inclusion separately
> >
> > the store does not do any indexing or file monitoring nor does it cosume
> > significant resources
>
> Couldn't you just make gio (or gedit or OpenOffice) notify you every
> time it closes a file instead of monitoring bazillions of files? I'm
> not very likely to search for files I've never opened anyway.

Uh, generally bugs should be fixed, not worked around. Especially if
they are as crucial as this one.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Jamie McCracken-2]

On Tue, 2009-08-18 at 16:18 +0100, Martyn Russell wrote:

> On 18/08/09 16:18, Jamie McCracken wrote:
> > The indexer part is optional
>
> Well, right now it isn't but it will be at some point sure.
>
> > The main part tracker-store is just a database with querying and is to
> > be used by zeitgeist
> >
> > If the consensus is that indexer is not suitable for inclusion then the
> > separate tracker-store should be considered for inclusion separately
>
> That doesn't make any sense to me either. On its own it is useless then,
> at least with the file system crawler it can populate the database and
> be usable.

Its not useless if apps like zeitgeist are going to populate it with
their data and then query on it

The file crawler is only one such datasource but zeitgeist and other
apps can be datasources too

jamie

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Xan Lopez-3]

On Tue, Aug 18, 2009 at 6:21 PM, Lennart Poettering<mztabzr@...> wrote:

> On Tue, 18.08.09 11:18, Jamie McCracken (jamie.mccrack@...) wrote:
>
>>
>> The indexer part is optional
>>
>> The main part tracker-store is just a database with querying and is to
>> be used by zeitgeist
>>
>> If the consensus is that indexer is not suitable for inclusion then the
>> separate tracker-store should be considered for inclusion separately
>>
>> the store does not do any indexing or file monitoring nor does it cosume
>> significant resources
>
> I have no idea what "tracker-store" is. Please elaborate. It sounds as
> it was the database that is normally filled by the indexing data, but
> what could it be good for if you rip out the indexer?

It can be used directly by applications that feed it data through an
API. Zeitgeist is an example, another could be bookmarks/history
storage in Epiphany.

Xan

>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Patryk Zawadzki]

On Tue, Aug 18, 2009 at 5:23 PM, Lennart Poettering<mztabzr@...> wrote:
> Uh, generally bugs should be fixed, not worked around. Especially if
> they are as crucial as this one.

Sure but getting a recursive inotify will likely take years as with
most kernel features (= development time + significant adoption time).

--
Patryk Zawadzki
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Maciej Piechotka]

On Tue, 2009-08-18 at 17:20 +0200, Patryk Zawadzki wrote:

> On Tue, Aug 18, 2009 at 5:18 PM, Jamie
> McCracken<jamie.mccrack@...> wrote:
> > The indexer part is optional
> >
> > The main part tracker-store is just a database with querying and is to
> > be used by zeitgeist
> >
> > If the consensus is that indexer is not suitable for inclusion then the
> > separate tracker-store should be considered for inclusion separately
> >
> > the store does not do any indexing or file monitoring nor does it cosume
> > significant resources
>
> Couldn't you just make gio (or gedit or OpenOffice) notify you every
> time it closes a file instead of monitoring bazillions of files? I'm
> not very likely to search for files I've never opened anyway.
>

Well. What if the file was modified by no-gio app? Like KDE app or
command-line app?

Regards


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Jamie McCracken-2]

On Tue, 2009-08-18 at 17:20 +0200, Patryk Zawadzki wrote:

> On Tue, Aug 18, 2009 at 5:18 PM, Jamie
> McCracken<jamie.mccrack@...> wrote:
> > The indexer part is optional
> >
> > The main part tracker-store is just a database with querying and is to
> > be used by zeitgeist
> >
> > If the consensus is that indexer is not suitable for inclusion then the
> > separate tracker-store should be considered for inclusion separately
> >
> > the store does not do any indexing or file monitoring nor does it cosume
> > significant resources
>
> Couldn't you just make gio (or gedit or OpenOffice) notify you every
> time it closes a file instead of monitoring bazillions of files? I'm
> not very likely to search for files I've never opened anyway.
>

we could use the Gtk Recent files stuff for this and that would work for
ordinary users but not devs fetching source code or other command line
stuff

jamie

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Lennart Poettering-5]

On Tue, 18.08.09 17:26, Patryk Zawadzki (patrys@...) wrote:

>
> On Tue, Aug 18, 2009 at 5:23 PM, Lennart Poettering<mztabzr@...> wrote:
> > Uh, generally bugs should be fixed, not worked around. Especially if
> > they are as crucial as this one.
>
> Sure but getting a recursive inotify will likely take years as with
> most kernel features (= development time + significant adoption time).

That is not true.

And even if it was, distributions tend to merge kernel patches into
the distribution kernels before they are merged upstrem if it is likely
that it will end up there eventually. So this is really not an
argument here.

We are in the lucky position to have control on the full system, the
kernel as well as userspace. While the general processes might be a
bit different in the end it's not that much harder to get something
into the kernel than into is to get it into glib or glibc or whatever.

Don't believe that the kernel folks are inacessible people one
couldn't talk to.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list