GtkHTML - looking for a new maintainer
Hello, an Evolution team did maintain the GtkHTML in the past, because it was its main component for a mail composer. This changed with a 3.13.3 release, when Evolution begun to use WebKit based composer. The 3.14.0 will be released together with GNOME 3.16.0, spring 2015 (Evolution currently doesn't follow GNOME release schedule, 3.12.x, which is still using GtkHTML, will be supported until the 3.14.0 is out). The GtkHTML is in a maintenance mode for several years now and as the Evolution is not using it anymore, then I'd like to ask, whether anybody is willing to take the ownership of the GtkHTML. According to Fedora rawhide (to be Fedora 22) the only package which requires it is evolution-rss, and even that might be easily fixable. Due to that I suggest that either a new maintainer will be found or do archive it in time of the GNOME 3.16.0 (Evolution 3.14.0) release. This gives enough time to any willing maintainer to speak up. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel maintainers
Hi, On Mon, Sep 8, 2014 at 4:10 PM, Emmanuele Bassi wrote: > hi; > > On 8 September 2014 12:33, Alberts Muktupāvels > wrote: > > > I need some help and/or suggestion on how to take over gnome-panel > > maintaining. > > that's not how it works. > > I strongly suggest you discuss it with him, calmly, and productively, > in order to amicably solve this issue. > Does not look that it is possible otherwise I would not write this mail. > if nothing happens, you can create a clone of the gnome-panel > repository somewhere else, and convince others that your work is the > actual upstream. I'd strongly advise against this solution. > I don't think it would be good solution. > > Philipp does not want that I am taking over maintainership of > gnome-panel. > > Problem is that he is not maintaining it and does not want that I do > it... > > after reading the various threads it seems that he has concerns on the > quality of your contributions; have you tried improving them so that > his concerns will not be relevant any more? it also seems that he > rolled back your commits and instead moved them to topic branches for > ease of review and development. > He is only one who find problems with my contributions. Rolled back for what? First master was tested by separate users/distribution maintainers and it was reported that it works - works better than last release. At that time it was 3.8.0. Rolling back he lost at least one commit which is not available in topic branches nor in master. For ease of review? There is no one else who is going to review it. Was not it easier to look at code and if he finds something bad ask me to fix it rather than rolling back, creating new branches? For example he accepted GtkTable to GtkGrid changes in .ui files by other dev, but did not accept my commit that do some thing in code. I don't see any reason for this. Can you name any? > He is author of 16 commits. And at least half is not related to any fixes, > > just updating news, version bump, adding himself to maintainers. > > release management is a huge part of what "maintainer" means, > alongside code review, and integration of third party contributions. > I agree on this. But to make new release you need something new/improved/fixed... Is not that maintainers job too? He is just asking and mostly waiting until someone else will write patches, will review them. As I said he is not doing anything. Almost all work in last release is my work. So if I would not do anything how could he make new release? > > GNOME Panel is part of unofficial GNOME Flashback session (metacity, > > gnome-panel, gnome-applets). I am already maintaining gnome-applets, > > metacity. Also I have created new module that is very important part of > > Flashback session. > > Flashback is not really sanctioned by GNOME in any way, so the GNOME > community can at most suggest ways of solving this issue amicably. > It is not official part of GNOME, but still GNOME. Currently we speak about gnome-panel and there was time when gnome-panel was part of official GNOME session. What about maintainers that used to maintain gnome-panel while it was official part? Can not they help? Also I asked who approved him as maintainer. Till now he has not responded. Also I did not find any public discussions about it. So there is possibility that he simply took over maintaining. > > Mailing list subscribers is on my side. > > development and maintainership are not popularity contests. > Of course. It was not meant that way. I tried to say that basically Philipp is not happy with my work, but everyone else on mailing-list is not happy with his work. For example there was user who reported bug about broken EDS in clock applet. He just responded that it is working asking to do more testing, he even wrote that he tested. He was wrong. I found problem, I fixed it, I sent patches to mailing list. Did he even look at them? No. > ciao, > Emmanuele. > > -- > http://www.bassi.io > [@] ebassi [@gmail.com] > -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System services & jhbuild
Zeeshan Ali (Khattak) wrote: > > It does (basically it sets PKG_CONFIG_PATH to also look into the > > system directories, so if you have networkmanager development files > > installed, it will find them), and it even automatically skip modules > > that are installed with a proper version (but it has to know the > > required minimum version, and we used to maintain that appropriately > > with "external deps", less so thosedays). > > 1. Many users won't have the development packages installed for these > system services and thus this won't be any solution for them. What sri > meant (correct me if I'm wrong) is to simply leave system services to > system. jhbuild sysdeps checks for the presence of the pkg-config file, and will then ask packagekit to install the proper packages. And well, if an application needs the NetworkManager development files, and they are not installed on the system, and that's certainly less ideal than building correctly, because it had been built correctly by jhbuild five steps before. > 2. Not all services provide a library (e.g geoclue currently doesn't) > so deps are setup for runtime-only. In that case, build of such > services is almost always redundant. You were talking about "kicking out all system services from jhbuild"; and many of those services provide libraries. And geoclue provides a .pc file and modules are checking for it at configure time (from a quick grep: empathy, gnome-clocks, gnome-initial-setup, gnome-settings- daemon). > > Also, while it's not possible to run system services, it may still be > > useful to have them in jhbuild, as they provide libraries that will be > > used by other modules. For example it is required to have > > accountsservice libraries to build and run gnome-control-center, but > > most panels will be fine if the service itself is not running. > > If control-center would need latest of accountsservice, its likely > going to be because of new D-Bus API rather than just some convenience > API provided by the library, wouldn't it? If control-center (built in > jhbuild) can use the service from system at runtime, it can also use > the library from system? Nope, as Jasper wrote about the case of NetworkManager. > > Still, we may envision changes; for example it's now possible to have > > conditional modules, so perhaps we could work to have it both ways, > > with a default set without the system services, and a flag to enable > > them, a la "jhbuild --conditions=+system-services build". > > Although I can totally agree with going for this approach, I still > wonder what would user really achieve with this? Why build things that > in the end will be useless? As written before, they are not considered useless; heck, I even consider building geoclue2 to get its single .pc file installed useful. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System services & jhbuild
On Mon, Sep 8, 2014 at 6:32 PM, Frederic Peters wrote: > Sriram Ramkrishna wrote: >> On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak) >> wrote: >> > >> > Unless someone has plans on fixing this (somehow) soon, I would >> > suggest we either kick out all system services from jhbuild all >> > together or at least remove them from dependency list of other >> > modules. >> > >> +1 for me, It should try to use what is already on the system. > > It does (basically it sets PKG_CONFIG_PATH to also look into the > system directories, so if you have networkmanager development files > installed, it will find them), and it even automatically skip modules > that are installed with a proper version (but it has to know the > required minimum version, and we used to maintain that appropriately > with "external deps", less so thosedays). 1. Many users won't have the development packages installed for these system services and thus this won't be any solution for them. What sri meant (correct me if I'm wrong) is to simply leave system services to system. 2. Not all services provide a library (e.g geoclue currently doesn't) so deps are setup for runtime-only. In that case, build of such services is almost always redundant. > Also, while it's not possible to run system services, it may still be > useful to have them in jhbuild, as they provide libraries that will be > used by other modules. For example it is required to have > accountsservice libraries to build and run gnome-control-center, but > most panels will be fine if the service itself is not running. If control-center would need latest of accountsservice, its likely going to be because of new D-Bus API rather than just some convenience API provided by the library, wouldn't it? If control-center (built in jhbuild) can use the service from system at runtime, it can also use the library from system? >> Besides, what is the end goal of jhbuild? Is it to write code against >> the latest GNOME or is it to build a complete desktop environment? I >> would argue that we already have gnome-continuous for the latter. >> Reducing jhbuild's scope would help make it an easier tool to manage >> and actually work. > > It would certainly be easier but I don't foresee the double goal of > jhbuild changing much, because it still has to fulfil both in some > ways (as it's made to run in a VM, I don't feel like gnome-continuous > provides an appropriate testing/working environment). > > Still, we may envision changes; for example it's now possible to have > conditional modules, so perhaps we could work to have it both ways, > with a default set without the system services, and a flag to enable > them, a la "jhbuild --conditions=+system-services build". Although I can totally agree with going for this approach, I still wonder what would user really achieve with this? Why build things that in the end will be useless? -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System services & jhbuild
Sriram Ramkrishna wrote: > On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak) > wrote: > > > > Unless someone has plans on fixing this (somehow) soon, I would > > suggest we either kick out all system services from jhbuild all > > together or at least remove them from dependency list of other > > modules. > > > +1 for me, It should try to use what is already on the system. It does (basically it sets PKG_CONFIG_PATH to also look into the system directories, so if you have networkmanager development files installed, it will find them), and it even automatically skip modules that are installed with a proper version (but it has to know the required minimum version, and we used to maintain that appropriately with "external deps", less so thosedays). Also, while it's not possible to run system services, it may still be useful to have them in jhbuild, as they provide libraries that will be used by other modules. For example it is required to have accountsservice libraries to build and run gnome-control-center, but most panels will be fine if the service itself is not running. > Besides, what is the end goal of jhbuild? Is it to write code against > the latest GNOME or is it to build a complete desktop environment? I > would argue that we already have gnome-continuous for the latter. > Reducing jhbuild's scope would help make it an easier tool to manage > and actually work. It would certainly be easier but I don't foresee the double goal of jhbuild changing much, because it still has to fulfil both in some ways (as it's made to run in a VM, I don't feel like gnome-continuous provides an appropriate testing/working environment). Still, we may envision changes; for example it's now possible to have conditional modules, so perhaps we could work to have it both ways, with a default set without the system services, and a flag to enable them, a la "jhbuild --conditions=+system-services build". Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System services & jhbuild
The unfortunate thing is that with modules like NetworkManager, both nm-glib the library and NetworkManager the daemon, and sometimes we require new features and methods in the library, but not the daemon. I'd love to build and install just the library, but that just isn't possible with the build system it currently has. On Mon, Sep 8, 2014 at 10:59 AM, Sriram Ramkrishna wrote: > On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak) > wrote: > > > > Unless someone has plans on fixing this (somehow) soon, I would > > suggest we either kick out all system services from jhbuild all > > together or at least remove them from dependency list of other > > modules. > > > +1 for me, It should try to use what is already on the system. > Besides, what is the end goal of jhbuild? Is it to write code against > the latest GNOME or is it to build a complete desktop environment? I > would argue that we already have gnome-continuous for the latter. > Reducing jhbuild's scope would help make it an easier tool to manage > and actually work. > > sri > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System services & jhbuild
On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak) wrote: > > Unless someone has plans on fixing this (somehow) soon, I would > suggest we either kick out all system services from jhbuild all > together or at least remove them from dependency list of other > modules. > +1 for me, It should try to use what is already on the system. Besides, what is the end goal of jhbuild? Is it to write code against the latest GNOME or is it to build a complete desktop environment? I would argue that we already have gnome-continuous for the latter. Reducing jhbuild's scope would help make it an easier tool to manage and actually work. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
System services & jhbuild
Hi everyone, As many of you who use jhbuild regularly already know, system services (NetworkManager, ModemManager, geoclue etc) do not actually work when installed in custom prefixes as normal user. These services require to be installed on system to work. The result is that typically people either end up wasting their system resources and time building stuff that they won't have any use at all for, or putting these components in their skip list permanently. Unless someone has plans on fixing this (somehow) soon, I would suggest we either kick out all system services from jhbuild all together or at least remove them from dependency list of other modules. -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Sep 4, 2014 6:47 AM, "Allan Day" wrote: > None of this is new news of course - we've talked about it a lot in > the past, and some work has been done. The problem is that no one has > found the (probably significant) time to resolve the issues we're > facing. > We need a volunteer or many volunteer who can help here. Happily will mentor or find a mentor who is willing to put the time. Anybody interested in getting this reviewed and working? Sri > Allan > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Tracker] Proposed future for Tracker - Smaller modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/09/2014 12:34, Martyn Russell wrote:
Hi Martyn,
> Module = tracker-store - ontology (database schema) - libstemmer
> (stemming library used by libtracker-fts) - libtracker-common (type
> and various utilities) - libtracker-data (database access and
> implementation) - libtracker-fts (SQLite module for tokenising) -
> tracker-store (daemon providing DBus interface)
>
> Module = libtracker-sparql - libtracker-bus (DBus and read/write
> access to the DB) - libtracker-direct (readonly access to the DB) -
> libtracker-sparql-backend (internal implementation) -
> libtracker-sparql (public facing library to the DB)
My proposal would be to keep tracker-store, ontology and
libtracker-sparql together (as one project).
The reason for that is that the actual goal of libtracker-sparql was
to provide what libsqlite is for a RDMBS and SQL, but for RDF and SPARQL.
Without tracker-store, libtracker-sparql can't work.
By splitting the ontologies into a separate project, managed by the
Nepomuk organization or not, we could someday refactor
libtracker-sparql to support multiple instances of installed ontologies.
Ideal in that scenario would be that tracker-store becomes an impl.
detail of libtracker-sparql (it'll manage the instances of stores on a
on-demand basis).
The only real three reasons of existence of tracker-store are:
- GraphUpdated
- The fact that SQLite isn't MVCC and we need WAL journaling
and checkpointing done by a separate 'writer' process
- Providing a ontology
When your process links with libtracker-sparql and uses direct-access
mode, it effectively has everything it needs to deal with meta.db.
The eventual dependency tree would look like this:
Your program depends on:
|
+- nepomuk-ontology
|
+-libtracker-sparql
`- Internally uses libexec/tracker-sparql-store
This API:
https://developer.gnome.org/libtracker-sparql/stable/TrackerSparqlConnection.html
Would look like:
#include
#include
static void something ()
{
GError *error = NULL;
Ontology *ontology = nepomuk_ontology_2006_2008_new ("session id");
TrackerSparqlConnection *con =
tracker_sparql_connection_get_for_ontology (ontology)
TrackerSparqlCursor *cursor = tracker_sparql_connection_query (con,
"select ?a { ?a nie:title 'something in nepomuk' }",
NULL, &error);
while (tracker_sparql_cursor_next (cursor, NULL, NULL)) {
g_print ("%s\n", tracker_sparql_cursor_get_string());
}
g_object_unref (cursor);
g_object_unref (con);
g_object_unref (ontology);
}
This would internally deal with starting and stopping a
libexec/tracker-sparql-store, and no global "tracker-store" would be
needed anymore (the fact that multiple users share the same "session
id", creates the central storage for users of that "session id").
Storage could go to:
~/.tracker/sessions/$session-id/nepomuk-2006-2008/meta.db or something
Kind regards,
Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
iQEcBAEBAgAGBQJUDcOJAAoJEEP2NSGEz4aDAQQIAJ6arFvREfkh3tvieSwvvPLw
gDo7hP8XUHo42GaWC0bfSIV5cZalgN66zZN2uWjKDRba9zQ76F166lQQJ6l/LmlK
JQA0DvjuEQvLqR52dc8MDaC0H7D0dXFGWT3lhynCUxioyRPipDHVlwE0WlWEkfnR
CGQIeFK7ADgKi4Ae85cxsgJvN0GD3TGwigF10mTSjbLXCwXDyc+XdnBCwx3zFlQ+
H4S2avM3c/DlcPHfudJKy8Bm0qS7YmJxqnOdykkJVYJ3d4TIDf7uOarlkEwuCbxm
HraxGgq7xpT/7mIbUlTbS150cFhG/Q03ceeKkewLtfEcmBOEGuB9BRQFi+wJ8LU=
=4rYt
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Tracker] Proposed future for Tracker - Smaller modules
On 08/09/14 15:56, Philip Van Hoof wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/09/2014 12:34, Martyn Russell wrote:
Hi Martyn,
Hi Philip,
Module = tracker-store - ontology (database schema) - libstemmer
(stemming library used by libtracker-fts) - libtracker-common (type
and various utilities) - libtracker-data (database access and
implementation) - libtracker-fts (SQLite module for tokenising) -
tracker-store (daemon providing DBus interface)
Module = libtracker-sparql - libtracker-bus (DBus and read/write
access to the DB) - libtracker-direct (readonly access to the DB) -
libtracker-sparql-backend (internal implementation) -
libtracker-sparql (public facing library to the DB)
My proposal would be to keep tracker-store, ontology and
libtracker-sparql together (as one project).
The reason I didn't put libtracker-sparql with tracker-store / core
things is that logically it's quite a different thing for applications
wanting to JUST run SPARQL queries.
I suppose it doesn't make all that much difference, you still require
the store and other bits for libtracker-sparql to operate anyway.
I guess you could go as far as to say that you might want to JUST use
DBus and none of the libtracker-sparql support at all, another reason
for it being separate.
The reason for that is that the actual goal of libtracker-sparql was
to provide what libsqlite is for a RDMBS and SQL, but for RDF and SPARQL.
Yea, but libsqlite3 and sqlite are separate packages (actually I am not
sure if they're separate projects at all), but having tracker-store does
not mean you have to use libtracker-sparql.
Without tracker-store, libtracker-sparql can't work.
It's more the other way round I had in mind, without libtracker-sparql,
tracker-store works.
By splitting the ontologies into a separate project, managed by the
Nepomuk organization or not, we could someday refactor
libtracker-sparql to support multiple instances of installed ontologies.
I wouldn't split the ontologies out, the store is no good without the
database and without the schema it's even more useless :)
Besides, all the ontology validation and handling is in the libraries
the store depends on.
Ideal in that scenario would be that tracker-store becomes an impl.
detail of libtracker-sparql (it'll manage the instances of stores on a
on-demand basis).
The only real three reasons of existence of tracker-store are:
- GraphUpdated
- The fact that SQLite isn't MVCC and we need WAL journaling
and checkpointing done by a separate 'writer' process
Yea, single point of update.
- Providing a ontology
Not sure I follow you here, the reason for the store is not to provide
an ontology - at least libtracker-data does a lot of that stuff - I
would have to double check this.
The store offers a lot of buffering, queueing and general "management"
of updates (and queries). Let's not forget the DBus interface.
When your process links with libtracker-sparql and uses direct-access
mode, it effectively has everything it needs to deal with meta.db.
Indeed.
The eventual dependency tree would look like this:
Your program depends on:
|
+- nepomuk-ontology
|
+-libtracker-sparql
`- Internally uses libexec/tracker-sparql-store
This API:
https://developer.gnome.org/libtracker-sparql/stable/TrackerSparqlConnection.html
Would look like:
#include
#include
static void something ()
{
GError *error = NULL;
Ontology *ontology = nepomuk_ontology_2006_2008_new ("session id");
TrackerSparqlConnection *con =
tracker_sparql_connection_get_for_ontology (ontology)
TrackerSparqlCursor *cursor = tracker_sparql_connection_query (con,
"select ?a { ?a nie:title 'something in nepomuk' }",
NULL, &error);
while (tracker_sparql_cursor_next (cursor, NULL, NULL)) {
g_print ("%s\n", tracker_sparql_cursor_get_string());
}
g_object_unref (cursor);
g_object_unref (con);
g_object_unref (ontology);
}
Interesting idea.
This would internally deal with starting and stopping a
libexec/tracker-sparql-store, and no global "tracker-store" would be
needed anymore (the fact that multiple users share the same "session
id", creates the central storage for users of that "session id").
Storage could go to:
~/.tracker/sessions/$session-id/nepomuk-2006-2008/meta.db or something
This is quite an addition to what we have now.
I don't think it makes much difference because libtracker-sparql will
always depend on a tracker-store (or whatever alias you use for grouping
components that update the DB - libtracker-data, libtracker-fts, etc.).
Consider the application that only wants to query and not update the DB
- they don't want to depend on all the crap needed for updating the DB,
just the raw libtracker-sparql part.
--
Regards,
Martyn
Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell
__
Re: Proposed future for Tracker - Smaller modules
Hi, On Mon, Sep 08, 2014 at 07:30:38AM -0400, Matthias Clasen wrote: > - 2^x new module-module interfaces (It's x^2 (maximum x * (x-1) more precisely), not 2^x.) -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed future for Tracker - Smaller modules
On 08/09/14 12:30, Matthias Clasen wrote: On Mon, Sep 8, 2014 at 6:34 AM, Martyn Russell wrote: What is the goal? - What I would like to achieve is: 1. Make it easier to build just what's needed (e.g. just tracker-store), i.e. more modular. 2. Make development and maintenance easier by moving components to their own projects so development can be focused 3. Make a clear distinction between *core* functionality and "nice to have stuff". 4. I would like to unify the command line utilities a bit more similarly to how git operates, so instead of 'tracker-control -r', 'tracker control -r', etc. But is it worth the downside ? Good question. - x times as much configure goo I'm not so worried about the configure stuff, actually, I would like to have simpler files to work with :) the current configure script for Tracker is quite long. - 2^x new module-module interfaces I agree with you on this one. - plenty of new opportunities for version skew and build breakage So I mentioned a lot of reasons which are more personally related since I'm building and maintaining the project a lot. Let me expand a little... 5. The pace of development for some modules is quite different to others: $ git log --oneline --since=1.year src/tracker-store | wc -l 8 $ git log --oneline --since=1.year src/libtracker-miner | wc -l 127 Some places have no changes for a while now ... 6. Some use cases for Tracker are limited to a headless system where only the store is required, this makes half of the code base completely irrelevant. An example here is embedded cases like set top boxes. Companies could avoid patching OR building dependencies they're not going to use or don't want to use anyway making their footprint smaller too. 7. If I want to use a new feature as a developer working with Tracker, I should be able to build the module with that feature (e.g. libtracker-sparql) and not ALL of tracker. I guess this is related to your version fragmentation, but there are advantages too, like micro or regular releases for each component. I had an example like this the other day where I wanted to use the ontology from one branch but the binaries from another to test a bug. Generally, I don't think it's a good idea to have huge modules (I did for a while) and that's one of the reasons I split out libmediaart, the code there (however crap at the moment), doesn't really change that often either and I can fix that independently and easily. I am happy to listen to the community and decide based on input received, after all you guys are using Tracker and building it :) Thanks Matthias, -- Regards, Martyn Founder & Director @ Lanedo GmbH. http://www.linkedin.com/in/martynrussell ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel maintainers
hi; On 8 September 2014 12:33, Alberts Muktupāvels wrote: > I need some help and/or suggestion on how to take over gnome-panel > maintaining. that's not how it works. I strongly suggest you discuss it with him, calmly, and productively, in order to amicably solve this issue. if nothing happens, you can create a clone of the gnome-panel repository somewhere else, and convince others that your work is the actual upstream. I'd strongly advise against this solution. > Philipp does not want that I am taking over maintainership of gnome-panel. > Problem is that he is not maintaining it and does not want that I do it... after reading the various threads it seems that he has concerns on the quality of your contributions; have you tried improving them so that his concerns will not be relevant any more? it also seems that he rolled back your commits and instead moved them to topic branches for ease of review and development. > He is author of 16 commits. And at least half is not related to any fixes, > just updating news, version bump, adding himself to maintainers. release management is a huge part of what "maintainer" means, alongside code review, and integration of third party contributions. > GNOME Panel is part of unofficial GNOME Flashback session (metacity, > gnome-panel, gnome-applets). I am already maintaining gnome-applets, > metacity. Also I have created new module that is very important part of > Flashback session. Flashback is not really sanctioned by GNOME in any way, so the GNOME community can at most suggest ways of solving this issue amicably. > Mailing list subscribers is on my side. development and maintainership are not popularity contests. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Panel maintainers
Hi! I need some help and/or suggestion on how to take over gnome-panel maintaining. GNOME Panel currently has 3 maintainers Jonathan Carter, Josselin Mouette and Philipp Kaluza. I tried to contact Jonathan and Josselin (sent mail in Aug 19). Josselin did not respond. Jonathan responded and he does not object that I would take over gnome-panel maintaining. He wrote that he is not interested in gnome-panel anymore. Philipp does not want that I am taking over maintainership of gnome-panel. Problem is that he is not maintaining it and does not want that I do it... He is author of 16 commits. And at least half is not related to any fixes, just updating news, version bump, adding himself to maintainers. GNOME Panel is part of unofficial GNOME Flashback session (metacity, gnome-panel, gnome-applets). I am already maintaining gnome-applets, metacity. Also I have created new module that is very important part of Flashback session. Mailing list subscribers is on my side. They want that I am taking over gnome-panel maintaining. I have asked that in mailing list at least twice. Please see responses to these mails: 1) https://mail.gnome.org/archives/gnome-flashback-list/2014-August/msg00016.html 2) https://mail.gnome.org/archives/gnome-flashback-list/2014-July/msg3.html In master I had fixed some bugs, fixed some deprecated warnings to get it more up to date with newer GTK+ version. He asked to remove all that work from master. Two responses for that: 1) https://mail.gnome.org/archives/gnome-flashback-list/2014-September/msg3.html 2) https://mail.gnome.org/archives/gnome-flashback-list/2014-September/msg6.html Is there any way I could take over gnome-panel maintaining? Thanks! -- Alberts Muktupāvels ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed future for Tracker - Smaller modules
On Mon, 2014-09-08 at 07:30 -0400, Matthias Clasen wrote: > On Mon, Sep 8, 2014 at 6:34 AM, Martyn Russell wrote: > > > > > > > > What is the goal? > > - > > What I would like to achieve is: > > > > 1. Make it easier to build just what's needed (e.g. just > >tracker-store), i.e. more modular. > > 2. Make development and maintenance easier by moving components to > >their own projects so development can be focused > > 3. Make a clear distinction between *core* functionality and "nice to > >have stuff". > > 4. I would like to unify the command line utilities a bit more > >similarly to how git operates, so instead of 'tracker-control -r', > >'tracker control -r', etc. > > But is it worth the downside ? > - x times as much configure goo > - 2^x new module-module interfaces > - plenty of new opportunities for version skew and build breakage Though splitting up tools that use public interfaces, such as the plugins or the GUIs should be fine. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed future for Tracker - Smaller modules
On Mon, Sep 8, 2014 at 6:34 AM, Martyn Russell wrote: > > > What is the goal? > - > What I would like to achieve is: > > 1. Make it easier to build just what's needed (e.g. just >tracker-store), i.e. more modular. > 2. Make development and maintenance easier by moving components to >their own projects so development can be focused > 3. Make a clear distinction between *core* functionality and "nice to >have stuff". > 4. I would like to unify the command line utilities a bit more >similarly to how git operates, so instead of 'tracker-control -r', >'tracker control -r', etc. But is it worth the downside ? - x times as much configure goo - 2^x new module-module interfaces - plenty of new opportunities for version skew and build breakage ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed future for Tracker - Smaller modules
On 08/09/14 12:17, Bastien Nocera wrote: On Mon, 2014-09-08 at 11:34 +0100, Martyn Russell wrote: Hello all, So for some time now, I've been thinking that Tracker should be split into smaller parts. This has been suggested before and I've mentioned this a few times recently but not formally discussed it on the mailing list. So here we are :) Features are supposed to be end-user features. I see nothing here that benefits the users. Thanks Bastien, I know it's not a feature to split Tracker up, but I raised it on the list in case there was any feedback from the community about the plans. I guess I shouldn't have coincided this with the day feature proposals started being discussed :) -- Regards, Martyn Founder & Director @ Lanedo GmbH. http://www.linkedin.com/in/martynrussell ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed future for Tracker - Smaller modules
On Mon, 2014-09-08 at 11:34 +0100, Martyn Russell wrote: > Hello all, > > So for some time now, I've been thinking that Tracker should be split > into smaller parts. This has been suggested before and I've mentioned > this a few times recently but not formally discussed it on the mailing > list. So here we are :) Features are supposed to be end-user features. I see nothing here that benefits the users. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed future for Tracker - Smaller modules
On 08/09/14 11:34, Martyn Russell wrote:
Hello all,
...
Module = nautilus?
- nautilus plugin (provides tagging widget)
I forgot a few things here, namely:
Module = tracker (existing module):
- ALL tracker-{control|info|search|*} command line utilities.
Module = tracker-writeback:
- tracker-writeback (used for writing metadata back to files, e.g.
tags to images).
--
Regards,
Martyn
Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposed future for Tracker - Smaller modules
Hello all, So for some time now, I've been thinking that Tracker should be split into smaller parts. This has been suggested before and I've mentioned this a few times recently but not formally discussed it on the mailing list. So here we are :) What is Tracker? Well, put simply it's: a) a two GUIs (tracker-needle, tracker-preferences) b) a daemon to update the DB (tracker-store and ontology) c) a daemon to 'first-pass' index the file system (tracker-miner-fs) d) a daemon to 'second-pass' index the file system (tracker-extract) e) a database schema configuration - i.e. ontology f) a bunch of command line utilities: tracker-control tracker-info tracker-import tracker-search tracker-sparql tracker-stats tracker-tag g) a series of libraries (only a few of which are public): libstemmer libtracker-bus libtracker-common libtracker-control (public) libtracker-data libtracker-direct libtracker-extract libtracker-fts libtracker-miner (public) libtracker-sparql (public) libtracker-sparql-backend h) a series of plugins: evolution (broken) firefox nautilus thunderbird There are a lot of other things packaged too, like functional tests, examples, unit tests, documentation, man pages, some utilities (e.g. sandboxing), etc. What is the goal? - What I would like to achieve is: 1. Make it easier to build just what's needed (e.g. just tracker-store), i.e. more modular. 2. Make development and maintenance easier by moving components to their own projects so development can be focused 3. Make a clear distinction between *core* functionality and "nice to have stuff". 4. I would like to unify the command line utilities a bit more similarly to how git operates, so instead of 'tracker-control -r', 'tracker control -r', etc. WHY? In a lot of cases, all binaries do not need to be re-built each time a feature is being developed, yet right now it is. If I want to test a feature branch for tracker-miner-fs, I have to build and install the whole of tracker-store, ontologies, and often (depending on build options), that includes unit tests, documentation for each component too. This takes up time when switching between various feature branches and most of the time there is no reason to re-build half of the code again. It's obvious that tracker-store is the core and so is the ontology it uses. Some of the libraries are too, but things like tracker-miner-fs is optional depending on what you're using Tracker for. This becomes even more apparent for some binaries like tracker-needle. I recently added a ./configure option --enable-minimal to only build tracker-store and this would be easier if it was just in a separate repository. Finally, making releases to fix something like the ontology or libraries should be much quicker, painless and easier for everyone involved to work with. How would this work? This is not entirely clear to me yet. I've started working on a branch to group data in the tree together for subcomponents, but it's not even close to being complete: https://git.gnome.org/browse/tracker/log/?h=data-in-binary-dirs I would like to hear any suggestions the community has about the best way to achieve this or what they would like from such a "break up". Right now the hardest part to work out is the (internal) libraries because some (like libtracker-common) are used by ALL components (pretty much). Here is an example of what we could (ideally) have (right now, I've not fully checked this is possible...): Module = tracker-store - ontology (database schema) - libstemmer (stemming library used by libtracker-fts) - libtracker-common (type and various utilities) - libtracker-data (database access and implementation) - libtracker-fts (SQLite module for tokenising) - tracker-store (daemon providing DBus interface) Module = libtracker-sparql - libtracker-bus (DBus and read/write access to the DB) - libtracker-direct (readonly access to the DB) - libtracker-sparql-backend (internal implementation) - libtracker-sparql (public facing library to the DB) Module = libtracker-miner - libtracker-miner (public facing library for miner base operations) Module = libtracker-control - libtracker-control (public facing library to control data miners) Module = tracker-data-miners - libtracker-extract (internal and used by tracker-extract) - tracker-miner-fs (1st pass indexing) - tracker-extract (2nd pass indexing) - tracker-miner-apps (indexes desktop files) - tracker-miner-rss (indexes RSS feeds) - tracker-miner-user-guides (indexes HTML and user documentation) - firefox (bookmarks) - thunderbird (emails) Module = tracker-preferences - tracker-preferences (configure options), mainly for tracker-miner-fs (NOTE: This is not really in line with GNOME's search configuration) Module = tracker-needle - tracker-nee
Re: git.gnome.org changes and new doap file requirements
Is desktop-devel-list the wrong place to ask how to use the new categories in doap files? An explanation is needed in https://wiki.gnome.org/Git/FAQ#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F. Den 2014-08-28 10:19, Kjell Ahlstedt skrev: When I tried to change libxml++.doap, git refused to push the changes. remote: ERROR: libxml++.doap is not valid: remote:doap:category property should be one of: apps,core,core-apps,deprecated,infrastructure The category in libxml++.doap is still bindings. I don't understand which one of the allowed categories suits libxml++. I haven't found any instructions have to use these categories. There are apps and core-apps. Why not libs and core-libs? https://wiki.gnome.org/Git/FAQ#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F still says that the allowed categories are admin, bindings, deprecated, desktop, development, infrastructure, platform, and productivity. Kjell Ahlstedt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
