Re: Module Proposal: Zeitgeist
+1 for me. I think there is some great potential for interesting features in GNOME. I've always been a big fan of the mapping of documents on a calendar so I know what I was working on a particular day. As a marketing guy, I'd like us to beat our competition with unique features that can't be seen on other platforms. sri -- Sriram Ramkrishna (sriram.ramkrishna_@@_...@.gmail.com (remove _@@_) On Tue, Apr 17, 2012 at 1:47 PM, Seif Lotfy s...@lotfy.com wrote: *Purpose: *Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. *Preamble: *It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: - Not enough integration with GNOME applications - Project hosting difficulties - Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: - Sorting search results according to frequency/recency - Populating dashboards - Finding files/contacts/etc... that are used together - History browser - Associating locations to items (used at location X or Y) - scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have *GNOME specific developments*: - We already log everything that pushes into Gtk.RecentlyUsed. - For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. - We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. - Additionally, the team wrote several plugins for GNOME Shell [2][3][4] - Integration with telepathy-folks is currently under development. - Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. We have moved to freedesktop.org so we can play nicely with GNOME, KDE, Ubuntu as well as others. [7] Since we are not a GNOME dependency some projects hesitate to integrate with us. It is a chicken and egg problem. Applications don't want to depend on us since we are not GNOME upstream (thus only soft-dependencies) and GNOME hesitates to accept Zeitgeist since no application fully depends on it. For example: We want to use Zeitgeist in GNOME Clocks will to store alarms as scheduled activities. However we are not sure if we can do that without Zeitgeist being an external dependency. Another example, Epiphany integration: Zeitgeist could take over storing Epiphany history. However due to the uncertain state of Zeitgeist in GNOME we can not move on. I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd be happy to add support for it in Epiphany. *Some interesting facts about Zeitgeist: * - It is a dependency for Ubuntu Unity - Many application specific plugins that make use of what Zeitgeist has got to offer. - Integration into Phonon, the KDE multimedia framework and various deployments within KDE - Deploying in Dawati [0] - Paid dedicated developers - Previously ported from Python to Vala without breaking API *Proposal to become a blessed dependency *With this appliation I would like to address the possibility of accepting Zeitgeist as a blessed dependency. *Dependencies*: - Vala - Sqlite - Xapian (Soft) - python-rdflib (only for compiling the ontologies) *Resource usage: * - Bug tracker: http://bugs.freedesktop.org/ - VCS: http://cgit.freedesktop.org/zeitgeist/ *Other notes: *What most people think of as Zeitgeist is split in two processes zeitgeist-daemon and zeitgeist-datahub. The daemon does not do any active monitoring for events, it only manages the log database and exposes a DBus interface for inserting, deleting, querying
Re: Module Proposal: Zeitgeist
You know, when I first stumbled on zeitgeist running on my system a year or so ago, I didn't know what in the world it was doing, although it appeared to be logging... something. And I think I probably forced it to quit out of pure habit, before going online to figure out what it was actually doing. For the next few months I was pretty ambivilant about having it logging stuff on my system, and continued to kill it occasionally without really know what it was doing :p. And then I realized something - its actually quite useful. By keeping *ALL* logging in one place, it makes it much easier to keep track of, and also much easier to make sure that only those applications, etc which you want to be logged are actually logged. Of course, this is made immeasurabley easier w/ the awesome privacy settings in Ubuntu 12.04 (I'm honestly not sure - does such a thing exist in other distros?). Anyhow, to the point at hand... With GNOME-Clocks, having zeitgeist keep track of alarms, timers, etc makes sense since it allows users to close clocks when not in direct use, thereby saving resources while also keeping their alarms/timers/etc in place. The same I imagine is true for Epiphany/Web as well as many other programs. It also of course enables users to easily erase logs if/when they so choose, which is, IMHO just as important these days as keeping logs in the first place, if not more so. Emily -- Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it. - Goethe Be who you are and say what you feel because those who mind don't matter and those who matter don't mind. - Dr.Seuss Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. As an example, Seif has asked me to clarify that libfolks is happy to have Zeitgeist as a hard dependency if other core modules also have Zeitgeist as a hard dependency. In the meantime, we plan to have Zeitgeist as a soft dependency (just like most of our other dependencies) since it isn't used for too much in folks at the moment, and it's another thing which people would otherwise be forced to build before they could build folks for themselves. See https://bugzilla.gnome.org/show_bug.cgi?id=672709 for details on Zeitgeist + folks. Philip Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, 2012-04-25 at 22:36 +0200, Frederic Peters wrote: Seif Lotfy wrote: So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Do note this was not discussed by the release team, we'll have a meeting soon and we can add that to the agenda if you want an official answer, but in my opinion there is no problem if a maintainer wants to use zeitgeist because it helps in whatever s/he is coding. As a data point, I have a branch in Yelp where I'm using Zeitgeist. I want to use it to reorder search results based on frequency. of access. At the moment, the branch is reporting to Zeitgeist, and it's adding links to often viewed with pages alongside the more about and see also links. (That bit is sort of an experiment. Time will tell how useful it is.) It's not entirely clear to me what the process would be for me to propose merging this to master, especially given that there's an existing module proposal for Zeitgeist. Though I wasn't going to worry about that anyway until I had the search result reordering working. (I'd rather discuss code than ideas.) I also have a long-term, wishful thinking goal of being able to collect usage data for Yelp. I still have to figure out how I can do this without violating privacy, but Zeitgeist already collects exactly the information I would want reported. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, 2012-04-22 at 20:45 +0300, Rūdolfs Mazurs wrote: Does design team use anything like meetbot? http://meetbot.debian.net/Manual.html As far as I know still no bots are used for managing and logging any GNOME IRC meetings. Also see the short discussion here: https://mail.gnome.org/archives/foundation-list/2011-May/msg00072.html On a related note I once started a draft to list teams and meetings on a central wikipage as an attempt to make collaboration and contribution slightly more accessible and transparent for interested parties: https://live.gnome.org/AndreKlapper/IrcMeetings If you or anybody else feels like pushing this goal, please go ahead as I don't plan to pick this up soon again (busy with other stuff). Thanks, andre -- mailto:ak...@gmx.net | failed 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: Openness (Was: Re: Module Proposal: Zeitgeist)
On Tue, Apr 24, 2012 at 2:54 PM, Andre Klapper ak...@gmx.net wrote: On Sun, 2012-04-22 at 20:45 +0300, Rūdolfs Mazurs wrote: Does design team use anything like meetbot? http://meetbot.debian.net/Manual.html The A11y team has a meetbot for logging meetings. They are the only team I know of that does. https://live.gnome.org/Accessibility/Meetings Meg Ford As far as I know still no bots are used for managing and logging any GNOME IRC meetings. Also see the short discussion here: https://mail.gnome.org/archives/foundation-list/2011-May/msg00072.html On a related note I once started a draft to list teams and meetings on a central wikipage as an attempt to make collaboration and contribution slightly more accessible and transparent for interested parties: https://live.gnome.org/AndreKlapper/IrcMeetings If you or anybody else feels like pushing this goal, please go ahead as I don't plan to pick this up soon again (busy with other stuff). Thanks, andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Emily, On Sun, 2012-04-22 at 10:27 -0400, Emily Gonyer wrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. Your criticism here has merit, but I would assert that there is some degree of this kind of insularity in many communities and organizations. A lot of communities rely implicitly on what in politics is called political capital - where to cause a change, particularly one that implies work by other people, you need to have built up some goodwill and/or reputation. In my work on the engineering side, I react completely differently to people who I know have contributed something already versus ones I don't know, because I have some assurance that by helping them solve their problem, they are likely to help me later in some way. But again, I'm not saying that there's no problem - there clearly are things we as a community could do significantly better. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Emily, On Tue, Apr 24, 2012 at 4:19 PM, Colin Walters walt...@verbum.org wrote: Hi Emily, On Sun, 2012-04-22 at 10:27 -0400, Emily Gonyer wrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. Your criticism here has merit, but I would assert that there is some degree of this kind of insularity in many communities and organizations. A lot of communities rely implicitly on what in politics is called political capital - where to cause a change, particularly one that implies work by other people, you need to have built up some goodwill and/or reputation. I agree, this is a really intimidating part of joining the community. When I was doing my OPW internship, I was also really intimidated by the Design Team in particular -- which was bad because I was working on a project with Design Team members. Part of the reason I felt that way was that there was a discussion a lot like this one going on on the mailing list. I'm not saying that I think the situation is perfect -- sometimes I have a hard time dealing with working in the open and the criticism that goes along with it. I do think (and I've contributed to design but no one has ever called me a design team member) that there are issues in the community that need to be resolved, so I think the discussion is productive, as long as we aren't sending a negative message to newcomers or letting the community splinter over issues like this. Meg Ford In my work on the engineering side, I react completely differently to people who I know have contributed something already versus ones I don't know, because I have some assurance that by helping them solve their problem, they are likely to help me later in some way. But again, I'm not saying that there's no problem - there clearly are things we as a community could do significantly better. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 08:33:43PM -0700, Sriram Ramkrishna wrote: What about you want to use a new technology but you don't want any new features but rather using this new external dependency will simpifiy things and making maintainance easier? I suppose that itself is the feature? Easier maintenance? That's #3 actually; propose a new external dependency (same as you do when you want to increase a new one). I know the process is still imperfect (e.g. I think we didn't do a feature request announcement yet, we should clearly announce which ones are 'accepted' + should've monitored the progress on accepted features). Result is that it that the 'rules' are unclear. I think in the end focussing on features instead of external dependencies is better. But I think the thought is still underway. Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Olav, Thanks a lot for clearing it up. This makes a lot of sense. As I see it there is two ways to approach this: 1) Implement first then propose as an external dependency:The risk is that implementation is done and GNOME decides the dependency is unacceptable, thus rendering a couple of months work useless. And if the application persists then it is almost like its shoving a dependency down the communities throat. 2) It is blessed to use the technology. This way we valuable time is saved and there is consensus. I prefer option 2. What do you think? Cheers Seif On Sun, Apr 22, 2012 at 12:14 PM, Olav Vitters o...@vitters.nl wrote: On Sat, Apr 21, 2012 at 08:33:43PM -0700, Sriram Ramkrishna wrote: What about you want to use a new technology but you don't want any new features but rather using this new external dependency will simpifiy things and making maintainance easier? I suppose that itself is the feature? Easier maintenance? That's #3 actually; propose a new external dependency (same as you do when you want to increase a new one). I know the process is still imperfect (e.g. I think we didn't do a feature request announcement yet, we should clearly announce which ones are 'accepted' + should've monitored the progress on accepted features). Result is that it that the 'rules' are unclear. I think in the end focussing on features instead of external dependencies is better. But I think the thought is still underway. Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote: do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. ... and from before the design team even existed, there are even more threads about design decisions that make the community powerless against the almighty GNOME Developers - the (rightful) answer to that is usually don't just complain, get involved. The same still holds true with the design team - really, those folks would *love* seeing more people getting involved. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. Emily On Sun, Apr 22, 2012 at 10:11 AM, Florian Müllner fmuell...@gnome.orgwrote: On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote: do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. ... and from before the design team even existed, there are even more threads about design decisions that make the community powerless against the almighty GNOME Developers - the (rightful) answer to that is usually don't just complain, get involved. The same still holds true with the design team - really, those folks would *love* seeing more people getting involved. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it. - Goethe Be who you are and say what you feel because those who mind don't matter and those who matter don't mind. - Dr.Seuss Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On 22 April 2012 06:14, Olav Vitters o...@vitters.nl wrote: Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. Off-topic, Ubuntu 12.04 won't have Boxes in the repositories, at least partly because the libvirt dependency was increased 2 weeks after The Freeze. But this was the first stable release of Boxes, I'm sure things will be better for 3.6. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
I agree with Florian here. It took me a bit of time to interact with the design team but it is possible. It is a very young team and extremely busy and overloaded. They are welcoming for anyone to work with them on design and once you get their attention they will help you integrate more. The best way to be heard is to get involved. But I also understand Luis. I have been working with Allan Day and others for a while now and they are a very productive. The missing point here is that maybe and only maybe because most of the designers are hired by RH (which i consider a blessing if you get paid to work for GNOME), they forget the social capital which is the community, that will implement the work they design. Without interaction with the community no work will be done. And by saying this has to be done because it was decided without any written form or communication it makes things harder. Yes I know there is a wiki but sometimes a developer wants to discuss design decisions but due to the lack of communication efforts from both sides, it seems that the decisions are taken by the design team. My point is that designers should communicate and respect the opinions of the developers. Developers don't just wait to the last moment. Get involved and discuss. I know every side has its own priorities, but we are a community and discussions and compromises need to be made. We want to deliver a product. Some of us get paid to do this, but not all of us. Most of us do it as fun and in our free time. We are a community, this means there is a social aspect involved. And if we can not nurture this social aspect, issues like these show up. Maybe the decision process is flawed. Sometimes technical aspects can not be decided by the design team and thus I would recommend having 2 types of proposals. a feature proposal (UX) and a module proposal (technical stuff). Regards Seif On Sun, Apr 22, 2012 at 4:11 PM, Florian Müllner fmuell...@gnome.org wrote: On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote: do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. ... and from before the design team even existed, there are even more threads about design decisions that make the community powerless against the almighty GNOME Developers - the (rightful) answer to that is usually don't just complain, get involved. The same still holds true with the design team - really, those folks would *love* seeing more people getting involved. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
While this thread reflects a bit about some community observations on how things are handled in GNOME, and i support such a discussion, I find it a bit off-topic. Can we start a new thread discussing these issues or so. Let us stay on topic. Can an applications use Zeitgeist for technical/optimization (NOT FEATURES OR UX) causes? And how does it proceed? 1) Implement first and require dependency later. 2) Request blessed dependency and then implement, if the blessing is given. I would like to know an answer from the release-team if possible, since this is not really design related. Cheers Seif On Sun, Apr 22, 2012 at 4:36 PM, Jeremy Bicha jbi...@ubuntu.com wrote: On 22 April 2012 06:14, Olav Vitters o...@vitters.nl wrote: Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. Off-topic, Ubuntu 12.04 won't have Boxes in the repositories, at least partly because the libvirt dependency was increased 2 weeks after The Freeze. But this was the first stable release of Boxes, I'm sure things will be better for 3.6. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 4:27 PM, Emily Gonyer emilyyr...@gmail.com wrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. First: the design team is very much trying to get stuff done, just like the rest of the community. In fact, the design team is incredibly small (ergo: overworked). We have an extremely ambitious goal of creating an operating system, with just a handful of people doing design work towards that goal - compare that to the resources the likes of Apple or Microsoft put into their products to get an idea of the workload our folks have. I certainly have seen maintainers asking for design help on #gnome-design being turned down because no designer had any time to spend on yet-another-module. Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - none of us does anything like that (I doubt you are adding comments like Using a full-blown GObject rather than a boxed type here because ... or This variable is a double and not an integer because ... to your code - I certainly don't. Still, wouldn't that be helpful for newcomers?). So what about the overall vision then? I don't disagree with you at all in that it is often pretty vague - not because the design team is being secretive about it, but because it is work-in-progress that we(*) are developing together as a community. Also, it is worth pointing out that the power of the design team is very much limited to convincing developers and maintainers of their work - if a design is not implemented, it pixel-rots on the wiki, if a maintainer does not like a patch, it doesn't get committed. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. From my own personal experience, I'd say that from the outside it looks a lot harder than it actually is, but that doesn't mean that there is no problem. Still, it is something that applies for the community at large, not just the design team - if someone presents a radical new vision for GTK+, it is very much relevant whether someone is Benjamin Otte or Emmanuele Bassi, or someone no one has ever heard of ... Regards, Florian (*) to clarify, that we includes developers - I don't identify myself as a member of the design team, but as GNOME hacker who gets along fine with them :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - none of us does anything like that (I doubt you are adding comments like Using a full-blown GObject rather than a boxed type here because ... or This variable is a double and not an integer because ... to your code - I certainly don't. Still, wouldn't that be helpful for newcomers?). That sounds like exactly the sort of thing I write in my git commit messages. I hope you do too. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
In the end your history is scattered all over the place :P The logs are there and there is not common way to manage them. Having a central log like Zeitgeist will allow you to develop policies and blacklist for logging. Having history at a central location and having a central tool to disable logging completely or partially should be considered as an improvement of the user security. The problem I see here is that it only improves the situation if it is truly universal - if a central privacy control offers an option to remove my recent activity from the last 2 hours, it'd better clear my firefox/chromium cookies as well(*). Otherwise users will either have to know about implementation details, or will end up with a false sense of control. Also - if I want to hide my recent activity on http://www.furnitureporn.com/, should that really affect funnycat1.png in recent files or my chat history with @fiancé? I am not saying that a central tool is bad per se, just that a feature like that should be designed *before* pushing a technology that implies a certain design. Regards, Florian (*) Maybe Canonical's downstream panel does that, I don't know - they are in a much stronger position here than we are upstream ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 7:09 PM, Florian Max florian.muell...@gmail.com wrote: In the end your history is scattered all over the place :P The logs are there and there is not common way to manage them. Having a central log like Zeitgeist will allow you to develop policies and blacklist for logging. Having history at a central location and having a central tool to disable logging completely or partially should be considered as an improvement of the user security. The problem I see here is that it only improves the situation if it is truly universal - if a central privacy control offers an option to remove my recent activity from the last 2 hours, it'd better clear my firefox/chromium cookies as well(*). Otherwise users will either have to know about implementation details, or will end up with a false sense of control. First of all thank you for bringing us on topic again. I agree with you. There is more to privacy than history. Cookies etc are involve. I am just saying history is a part of it. We can start from there. We all agree that design and implementation is iterative. Chrome is not a core app. GNOME should focus on the core apps (as stated by the designers) so a privacy manager should take only GNOME apps into consideration per default. Also - if I want to hide my recent activity on http://www.furnitureporn.com/, should that really affect funnycat1.png in recent files or my chat history with @fiancé? I am not saying that a central tool is bad per se, just that a feature like that should be designed *before* pushing a technology that implies a certain design. I totally 100% agree with you that from a UX perspective this needs much more design. And I already said I am not interested anymore in adding a new feature from a UX perspective. But just as a side note. The technology is there. Which means one you want to add a privacy thing it is there, and please believe me that managing your history via Zeitgeist is much more powerful than you give it credit. You can single out stuff and do whatever. It is missing a good UI. So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Regards, Florian (*) Maybe Canonical's downstream panel does that, I don't know - they are in a much stronger position here than we are upstream Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
Sv, 2012-04-22 12:36 -0400, Shaun McCance rakstīja: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Does design team use anything like meetbot? http://meetbot.debian.net/Manual.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 9:21 AM, Florian Max florian.muell...@gmail.comwrote: On Sun, Apr 22, 2012 at 4:27 PM, Emily Gonyer emilyyr...@gmail.comwrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. First: the design team is very much trying to get stuff done, just like the rest of the community. In fact, the design team is incredibly small (ergo: overworked). We have an extremely ambitious goal of creating an operating system, with just a handful of people doing design work towards that goal - compare that to the resources the likes of Apple or Microsoft put into their products to get an idea of the workload our folks have. I certainly have seen maintainers asking for design help on #gnome-design being turned down because no designer had any time to spend on yet-another-module. I think we have a bit of a problem. Our core team has gotten smaller and thus overworked. Because of that they don't have that kind of time to do community management. I would even say that some of you are kinda grumpy. :-) We really need to grow the number of good quality coders. Things like creating a lower bar of entry to code on GNOME is one aspect of an overall problem of getting new blood. It's why we have a perception of companies running the joint rather than a community. GNOME as a project needs to concentrate on bringing in new volunteers so that we can expand the core team. Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - Shaun opened up a new thread on this, I will pen my thoughts there. Great thoughts, Florian. Thanks. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance sha...@gnome.org wrote: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. So I think my point here is. Documenting is important but communication is key. I get it when designers think that they can spend your whole time trying to convince people of a vision, but at some point something needs to be done. I agree to a certain extent. But who will do it? The paid developers. Well this would make us lose the community on the long run. We need to work on communication between designers and developers. Build trust. Designers have to take time and push themselves to be patient with developers and explain to them seems to them to be trivial facts. Once developers understand how hard a designers job is they will respect it and trust in the decisions and vision, even if they don't agree in the beginning. But also designers need to work on growing they base. The entry level is not that easy I guess. We need to work on basics. If someone comes with designs that are not suitable for us, we can't just pus him away. The fact that he/she came over to discuss designs with us shows initiative to contribute. So some slight wording like You know that is really good, I am not sure how it can fit in our designs but would you try taking this view out and show me etc... We are not selling GNOME to consumers only. We are selling the community too. I like the subject of this thread, because openness does not only reflect on the decisions making process but also on the openness to accept new contributors. Cheers Seif Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - none of us does anything like that (I doubt you are adding comments like Using a full-blown GObject rather than a boxed type here because ... or This variable is a double and not an integer because ... to your code - I certainly don't. Still, wouldn't that be helpful for newcomers?). That sounds like exactly the sort of thing I write in my git commit messages. I hope you do too. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 1:06 PM, Seif Lotfy s...@lotfy.com wrote: On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance sha...@gnome.org wrote: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. No, you get volunteer community managers to communicate those design decisions. A community manager should be able to get a general feel of what design decisions are having issues with the community. At some point maybe sucha person can opt for a conversation with specific individuals but otherwise you know there are a lot of unreasonable people out here and the internet makes them more unreasonable than they would be usually. Luckily for us, we do have a number of people who couldu do that kind of community management, Olav for one has already been doing some of it. I do it more externally. Big projects like Mozilla have a community managers. It's definitely something this project should do more of. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 10:18 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: On Sun, Apr 22, 2012 at 1:06 PM, Seif Lotfy s...@lotfy.com wrote: On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance sha...@gnome.org wrote: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. No, you get volunteer community managers to communicate those design decisions. A community manager should be able to get a general feel of what design decisions are having issues with the community. At some point maybe sucha person can opt for a conversation with specific individuals but otherwise you know there are a lot of unreasonable people out here and the internet makes them more unreasonable than they would be usually. Good point. With community managers, designers can focus more. Still I think a minimal interaction with the community from the designers side is required. I think going with some kind of liaison is a good direction. Luckily for us, we do have a number of people who couldu do that kind of community management, Olav for one has already been doing some of it. I do it more externally. Are you talking about Olav Bacon :P (bad joke, trying to lighten the mood a bit) Big projects like Mozilla have a community managers. It's definitely something this project should do more of. Dave Eaves who is a Mozilla Community manager has a very nice talk I encourage everybody to watch it. http://blip.tv/djangocon/keynote-david-eaves-5571777 sri Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
I would like to quote Allan Day (from another public mail thread): --- I realise that you're frustrated by the lack of Zeitgeist adoption in GNOME, Seif. As I explained privately, the best way for you to pursue this is to talk to maintainers who might need it for search results. The decision to use Zeitgeist is really up to them. Allan --- I won't deny my frustration but I leared to live with it :P So let me ask a direct question: Is there any objections for a GNOME application/library/service whether core or not, to have a full dependency on Zeitgeist whether for technical reasons (optimization or features) or a UX reasons? If yes, then the chicken and egg problem is solved (for example Web is blessed to use Zeitgeist as its history storage) If no, what are the reasons? If the answer for that is propose a feature, (then we are back in the chicken and egg loop) Sometimes technical issues should be considered valid. So application maintainers don't have to take care of their logs (some technical outsourcing :P) Cheers Seif On Tue, Apr 17, 2012 at 10:47 PM, Seif Lotfy s...@lotfy.com wrote: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Preamble: It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: Not enough integration with GNOME applications Project hosting difficulties Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: Sorting search results according to frequency/recency Populating dashboards Finding files/contacts/etc... that are used together History browser Associating locations to items (used at location X or Y) scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have GNOME specific developments: We already log everything that pushes into Gtk.RecentlyUsed. For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. Additionally, the team wrote several plugins for GNOME Shell [2][3][4] Integration with telepathy-folks is currently under development. Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. We have moved to freedesktop.org so we can play nicely with GNOME, KDE, Ubuntu as well as others. [7] Since we are not a GNOME dependency some projects hesitate to integrate with us. It is a chicken and egg problem. Applications don't want to depend on us since we are not GNOME upstream (thus only soft-dependencies) and GNOME hesitates to accept Zeitgeist since no application fully depends on it. For example: We want to use Zeitgeist in GNOME Clocks will to store alarms as scheduled activities. However we are not sure if we can do that without Zeitgeist being an external dependency. Another example, Epiphany integration: Zeitgeist could take over storing Epiphany history. However due to the uncertain state of Zeitgeist in GNOME we can not move on. I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd be happy to add support for it in Epiphany. Some interesting facts about Zeitgeist: It is a dependency for Ubuntu Unity Many application specific plugins that make use of what Zeitgeist has got to offer. Integration into Phonon, the KDE multimedia framework and various deployments within KDE Deploying in Dawati [0] Paid dedicated developers Previously ported from Python to Vala without breaking API Proposal to become a blessed dependency With this appliation I would like to address the possibility of accepting Zeitgeist as a blessed dependency. Dependencies: Vala
Re: Module Proposal: Zeitgeist
I've talked to several of my coworkers, and they just think Zeitgeist is the right technology for anything they're trying to do. A number of people thought the time-based approach wasn't neat enough. They brought up the recent flames over the Recently Used selection by default in the GtkFileChooser. We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Some didn't like that Zeitgeist tried to record practically everything you did, they found it creepy. There might be an stigma against Zeitgeist, sure. But on the whole, I'm going to agree with them: Zeitgeist *isn't* the right technology for our finding and reminding strategy. On Sat, Apr 21, 2012 at 12:42 PM, Seif Lotfy s...@lotfy.com wrote: I would like to quote Allan Day (from another public mail thread): --- I realise that you're frustrated by the lack of Zeitgeist adoption in GNOME, Seif. As I explained privately, the best way for you to pursue this is to talk to maintainers who might need it for search results. The decision to use Zeitgeist is really up to them. Allan --- I won't deny my frustration but I leared to live with it :P So let me ask a direct question: Is there any objections for a GNOME application/library/service whether core or not, to have a full dependency on Zeitgeist whether for technical reasons (optimization or features) or a UX reasons? If yes, then the chicken and egg problem is solved (for example Web is blessed to use Zeitgeist as its history storage) If no, what are the reasons? If the answer for that is propose a feature, (then we are back in the chicken and egg loop) Sometimes technical issues should be considered valid. So application maintainers don't have to take care of their logs (some technical outsourcing :P) Cheers Seif On Tue, Apr 17, 2012 at 10:47 PM, Seif Lotfy s...@lotfy.com wrote: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Preamble: It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: Not enough integration with GNOME applications Project hosting difficulties Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: Sorting search results according to frequency/recency Populating dashboards Finding files/contacts/etc... that are used together History browser Associating locations to items (used at location X or Y) scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have GNOME specific developments: We already log everything that pushes into Gtk.RecentlyUsed. For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. Additionally, the team wrote several plugins for GNOME Shell [2][3][4] Integration with telepathy-folks is currently under development. Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. We have moved to freedesktop.org so we can play nicely with GNOME, KDE, Ubuntu as well as others. [7] Since we are not a GNOME dependency some projects hesitate to integrate with us. It is a chicken and egg problem. Applications don't want to depend on us since we are not GNOME upstream (thus only soft-dependencies) and GNOME hesitates to accept Zeitgeist since no application fully depends on it. For example: We want to use Zeitgeist in GNOME Clocks will to store alarms as scheduled activities. However we are not sure if we can do that without Zeitgeist being an external dependency. Another example, Epiphany
Re: Module Proposal: Zeitgeist
On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? Where is this plan? And why isn't it going through the feature proposal process? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. -- Shaun -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Shaun McCance wrote: Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. Indeed, there have been a few pages added on the wiki[1], some ported from 3.4, but it would really help the discussion if proponents were to send emails to this list. Also if there are features under discussion that are not listed over there, please add them, and bring the discussion over here. Thanks, Fred [1] https://live.gnome.org/ThreePointFive/Features ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. This makes me belive that the community no longer has the power to decide anything that aren't the way that the designers planned, please don't do the same as the projects you always criticise!** Now talking about Zeitgeist it seems to me that it proved stability and further adoption on other projects but not the project it was designed at the beginning (am i right Sief ?). The maintainers are very open to suggestions and to improve the adoption on more modules. So this is a big +1 for the inclusion. But still care to explain what should we do with tracker ? Should we use both ? Cheers Luis 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 6:59 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. These issues have been discussed at length on ddl in the past [1] and I believe that the relevant features have been through the process. For the 3.4 release we had emails [2, 3] and information on the wiki [4], for example. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. I think that the community has been given an opportunity to discuss these proposals. Boxes was essentially rejected last round, if memory serves me correctly. I'm not saying that the feature proposal process is perfectly clear though. ;) Allan [1] https://mail.gnome.org/archives/desktop-devel-list/2010-April/msg00085.html [2] https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg3.html [3] https://mail.gnome.org/archives/desktop-devel-list/2011-November/msg00014.html [4] https://live.gnome.org/ThreePointThree/Features ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
OK seems like i sent the mail to only Jasper (damn-reply to all) Again I repeat. I am not talking about features. Web is using an SQLite DB to store its HISTORY. This is code that they need to maintain themselves. Are the Web developers allowed and blessed to use Zeitgeist to store that history. This way we can maintain it. Provide them with a maintainer technology that allows more options and future expansion. It is a simple yes or no question? :D While I 100% agree with how creepy Zeitgeist might sound. How things are going: * Chat will store its history in its own DB * Web will store its history in its own DB * Documents has access to recently used. In the end your history is scattered all over the place :P The logs are there and there is not common way to manage them. Having a central log like Zeitgeist will allow you to develop policies and blacklist for logging. Having history at a central location and having a central tool to disable logging completely or partially should be considered as an improvement of the user security. The trick is to make the user aware of such options. Cheers Seif On Sat, Apr 21, 2012 at 6:59 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: I've talked to several of my coworkers, and they just think Zeitgeist is the right technology for anything they're trying to do. A number of people thought the time-based approach wasn't neat enough. They brought up the recent flames over the Recently Used selection by default in the GtkFileChooser. We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Some didn't like that Zeitgeist tried to record practically everything you did, they found it creepy. There might be an stigma against Zeitgeist, sure. But on the whole, I'm going to agree with them: Zeitgeist *isn't* the right technology for our finding and reminding strategy. On Sat, Apr 21, 2012 at 12:42 PM, Seif Lotfy s...@lotfy.com wrote: I would like to quote Allan Day (from another public mail thread): --- I realise that you're frustrated by the lack of Zeitgeist adoption in GNOME, Seif. As I explained privately, the best way for you to pursue this is to talk to maintainers who might need it for search results. The decision to use Zeitgeist is really up to them. Allan --- I won't deny my frustration but I leared to live with it :P So let me ask a direct question: Is there any objections for a GNOME application/library/service whether core or not, to have a full dependency on Zeitgeist whether for technical reasons (optimization or features) or a UX reasons? If yes, then the chicken and egg problem is solved (for example Web is blessed to use Zeitgeist as its history storage) If no, what are the reasons? If the answer for that is propose a feature, (then we are back in the chicken and egg loop) Sometimes technical issues should be considered valid. So application maintainers don't have to take care of their logs (some technical outsourcing :P) Cheers Seif On Tue, Apr 17, 2012 at 10:47 PM, Seif Lotfy s...@lotfy.com wrote: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Preamble: It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: Not enough integration with GNOME applications Project hosting difficulties Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: Sorting search results according to frequency/recency Populating dashboards Finding files/contacts/etc... that are used together History browser Associating locations to items (used at location X or Y) scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have GNOME specific developments: We already log everything that pushes into Gtk.RecentlyUsed. For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. Additionally, the team wrote several plugins for GNOME Shell [2][3][4] Integration with telepathy-folks is
Re: Module Proposal: Zeitgeist
Hey Luis. Very good question. Zeitgeist and Tracker are compeletely different. Tracker is a metadata storage. It is used to store tags and information about files and other data on your computer. Zeitgeist is a log. It is a very intelligent and responsive log. We can not do what tracker providers. Tracker can not do what we provide. Zeitgeist has narrowed down its scope and domain of services to do one thing and do it good. There is no conflict of interest between Zeitgeist and Tracker. Tracker and Zeitgeist are encourages to be used together. Tracker is awesome for searching. Zeitgeist can then sort these search results according to recency, frequency or relevancy. Hope this answers your question. Cheers Seif On Sat, Apr 21, 2012 at 8:22 PM, Luis Medinas lmedi...@gnome.org wrote: Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. This makes me belive that the community no longer has the power to decide anything that aren't the way that the designers planned, please don't do the same as the projects you always criticise! Now talking about Zeitgeist it seems to me that it proved stability and further adoption on other projects but not the project it was designed at the beginning (am i right Sief ?). The maintainers are very open to suggestions and to improve the adoption on more modules. So this is a big +1 for the inclusion. But still care to explain what should we do with tracker ? Should we use both ? Cheers Luis 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. That's the problem in reception: No meeting logs, no mailing list, all non-transparent - welcome to GNOME Designers, the new cabal. It's up to GNOME designers to change this but I'm not sure if everybody recognizes the problem at all. andre -- mailto:ak...@gmx.net | failed 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: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 11:24 AM, Allan Day allanp...@gmail.com wrote: I'm not saying that the feature proposal process is perfectly clear though. ;) It's a little rough, because we are only talking about features; we don't really get to address new technologies or libraries that we might want to make an existing application use without changing any features. For instance, let's say Xan who has indicated some interest to use Zeitgist in Web wanted to use it but not add any new features but instead uses Zg to store bookmarks then really does this process help that? Does he even need to come on DDL and say anything? After all, as maintainer it's his call as far as I'm concerned if he wants Zeitgist to powr his bookmarks. sri Allan [1] https://mail.gnome.org/archives/desktop-devel-list/2010-April/msg00085.html [2] https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg3.html [3] https://mail.gnome.org/archives/desktop-devel-list/2011-November/msg00014.html [4] https://live.gnome.org/ThreePointThree/Features ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.org wrote: Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. This makes me belive that the community no longer has the power to decide anything that aren't the way that the designers planned, please don't do the same as the projects you always criticise!** See Alan's mail in this thread. sri Now talking about Zeitgeist 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
2012/4/21 Sriram Ramkrishna s...@ramkrishna.me On Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.org wrote: Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. Sriram, do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. I don't want to point fingers to companies which i have much to thank for their hard work, specially their developers, but it's too much coincidence to have all these design decisions from the same people to go against all the community and also to developers who want to share their work with the GNOME Project just because it's not planned on the Design Team. Cheers Luis This makes me belive that the community no longer has the power to decide anything that aren't the way that the designers planned, please don't do the same as the projects you always criticise!** See Alan's mail in this thread. sri Now talking about Zeitgeist 2012/4/21 Shaun McCance sha...@gnome.org On Sat, 2012-04-21 at 13:46 -0400, Jasper St. Pierre wrote: On Sat, Apr 21, 2012 at 1:20 PM, Shaun McCance sha...@gnome.org wrote: On Sat, 2012-04-21 at 12:59 -0400, Jasper St. Pierre wrote: We have a design and a plan for finding and reminding, and Zeitgeist doesn't seem like the right technology to implement that plan. Who's we? We, the GNOME designers. Where is this plan? It's called Documents, and Photos, and Videos, and Music... basically, anything in here: https://live.gnome.org/Design/Apps And why isn't it going through the feature proposal process? I believe it has. I'm not seeing it in my mail archives. Your previous email seems to indicate that the features for 3.6 are already a foregone conclusion, and that Zeitgeist doesn't fit into that. But that just can't be, because WE the GNOME community decide what's in the next version right here on d-d-l during the proposal period. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 12:28 PM, Luis Medinas lmedi...@gnome.org wrote: 2012/4/21 Sriram Ramkrishna s...@ramkrishna.me On Sat, Apr 21, 2012 at 11:22 AM, Luis Medinas lmedi...@gnome.orgwrote: Hi, thanks Shaun for your reply, unfortunatly looks like who decides everything for GNOME Project are the Design team or the RedHat employees and not the community. Please, can we not finger specific companies when you write this? There isn't some cabal out there. It' shard for me to start taking anything seriously after the eye rolling after seeing this statement. Sriram, do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. I don't want to point fingers to The only point to my response was that fingering Red Hat specifically as part of a cabal is not productive. If people have issues then they should bring it up on foundation-list in a clear and concise manner. Most of what I've seen on shell list has been a re-hash of issues long discussed from 3.0 days. companies which i have much to thank for their hard work, specially their developers, but it's too much coincidence to have all these design decisions from the same people to go against all the community and also to developers who want to share their work with the GNOME Project just because it's not planned on the Design Team. In general, I think we should just address the issue and not drag in Red Hat, or Canonical or whatever the company du jour is. Again, it just distracts from the argument. That's all I'm saying. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 11:48:59AM -0700, Sriram Ramkrishna wrote: For instance, let's say Xan who has indicated some interest to use Zeitgist in Web wanted to use it but not add any new features but instead uses Zg to store bookmarks then really does this process help that? Does he even need to come on DDL and say anything? After all, as maintainer it's his call as far as I'm concerned if he wants Zeitgist to powr his bookmarks. Essentially: * If you propose a new feature, it is accepted and it requires some new dependency: go ahead * If you want a new external dependency in an existing module: request approval or propose it as a new feature The point is that we don't want new external dependencies. But if you have a new feature, then make a choice propose it, and once accepted, run with it. The goal is having a new feature, if you need something to make the feature happen, use it. Further, this nicely avoids the cases where external dependencies have been approved, but actually nothing used it for various releases. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 8:10 PM, Olav Vitters o...@vitters.nl wrote: On Sat, Apr 21, 2012 at 11:48:59AM -0700, Sriram Ramkrishna wrote: For instance, let's say Xan who has indicated some interest to use Zeitgist in Web wanted to use it but not add any new features but instead uses Zg to store bookmarks then really does this process help that? Does he even need to come on DDL and say anything? After all, as maintainer it's his call as far as I'm concerned if he wants Zeitgist to powr his bookmarks. Essentially: * If you propose a new feature, it is accepted and it requires some new dependency: go ahead * If you want a new external dependency in an existing module: request approval or propose it as a new feature Thanks Olav for making that clearer. Maybe something for the FAQ? This will eliminate discussions on libraries and external dependencies. This also seems to make things a lot easier. The point is that we don't want new external dependencies. But if you have a new feature, then make a choice propose it, and once accepted, run with it. The goal is having a new feature, if you need something to make the feature happen, use it. Further, this nicely avoids the cases where external dependencies have been approved, but actually nothing used it for various releases. What about you want to use a new technology but you don't want any new features but rather using this new external dependency will simpifiy things and making maintainance easier? I suppose that itself is the feature? Easier maintenance? sri -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Sounds like a reasonable approach. The reason we looked at zg in the first place is because we were told that eds might not be a good solution for this. I implement it how you suggested and demo it u guess :) On 4/19/12, Rodrigo Moya rodr...@gnome-db.org wrote: On Thu, 2012-04-19 at 10:31 +0100, Bastien Nocera wrote: On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote: Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? I think that somebody with a hammer sees every problem as a nail. You don't need to store alarms in Zeitgeist, you need to store the fact that the alarm went off in Zeitgeist. why not store them in e-d-s? you can create a separate calendar, disabled for viewing in the Evolution UI, which contains the events with the alarms. Thus, you don't need to have anything other than the already running evolution-alarm-notify process. You can even, IIRC, set up the alarm so that it runs an application, rather than showing the Evolution alarm dialog. cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2012-04-19 at 02:20 +0200, Seif Lotfy wrote: So let me try to take Web use cases that could use Zeitgeist: * The user wants to type in the location bar and have suggestions pop out while typing. * The user wants to blacklist some websites or all websites starting with porn from being stored in history * The user wants to disable history completely temporary * The user want to know where he downloaded a file from And quoting you: This has nothing to do with design honestly. Seems that you disagree with yourself. How do you know if something is the right tool when you don't know what you're going to build? You should focus on that. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote: Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? I think that somebody with a hammer sees every problem as a nail. You don't need to store alarms in Zeitgeist, you need to store the fact that the alarm went off in Zeitgeist. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 19, 2012 at 11:31 AM, Bastien Nocera had...@hadess.net wrote: On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote: Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? I think that somebody with a hammer sees every problem as a nail. You don't need to store alarms in Zeitgeist, you need to store the fact that the alarm went off in Zeitgeist. Both are stored into Zeitgeist. The fact that there was a scheduled event (alarm) is there until the alarm time is reached. The entry is then changed from scheduled activity to a notification. This is technical really I think we should take this into irc. Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 19, 2012 at 11:29 AM, Bastien Nocera had...@hadess.net wrote: On Thu, 2012-04-19 at 02:20 +0200, Seif Lotfy wrote: So let me try to take Web use cases that could use Zeitgeist: * The user wants to type in the location bar and have suggestions pop out while typing. * The user wants to blacklist some websites or all websites starting with porn from being stored in history * The user wants to disable history completely temporary * The user want to know where he downloaded a file from And quoting you: This has nothing to do with design honestly. Seems that you disagree with yourself. How do you know if something is the right tool when you don't know what you're going to build? Please elaborate. Who doesn't know what. On our side we know what we can provide. You took two mails and crossed addrssed them. In my first mail i addressed some *technical* not *usability* improvements in Web that we could provide. I don't see how I disagreed with myself there. In my second mail I am trying to list overall technical and usability ideas. Or did I understand your mail wrong? You should focus on that. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2012-04-19 at 10:31 +0100, Bastien Nocera wrote: On Wed, 2012-04-18 at 23:43 +0200, Seif Lotfy wrote: Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? I think that somebody with a hammer sees every problem as a nail. You don't need to store alarms in Zeitgeist, you need to store the fact that the alarm went off in Zeitgeist. why not store them in e-d-s? you can create a separate calendar, disabled for viewing in the Evolution UI, which contains the events with the alarms. Thus, you don't need to have anything other than the already running evolution-alarm-notify process. You can even, IIRC, set up the alarm so that it runs an application, rather than showing the Evolution alarm dialog. cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le mardi 17 avril 2012 à 22:47 +0200, Seif Lotfy a écrit : Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Preamble: It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: * Not enough integration with GNOME applications * Project hosting difficulties You didn't say anything about the places integration to the core desktop, i.e. the Shell and the Documents app. I think this is the key point. What's the status of the experimental Finding and Reminding view that was based on Zeitgeist[1] and of the Shell extension[2]? Have you discussed with designers about that recently? I'm all for adding Zeitgeist as a dependency, but the essential question is (and has been since the beginning) how to make the best use of it in the core desktop. IMHO that's where you can break the chicken-and-egg vicious cycle. My two cents 1: http://people.gnome.org/~federico/news-2011-02.html#zeitgeist-in-gnome-shell 2: https://extensions.gnome.org/extension/62/journal/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Seif, FYI we dropped the module proposals period and replaced it by a proposal period for systemwide features. See https://mail.gnome.org/archives/devel-announce-list/2012-March/msg5.html for the GNOME 3.5 call. So the question would turn into Which (Zeitgeist-based) features could become part of GNOME 3.6 and what are the advantages for the GNOME system. As far as I see this is already answered by your section below, both by describing systemwide functionality provided by Zeitgeist and by listing several GNOME modules with existing or planned integration code. andre On Tue, 2012-04-17 at 22:47 +0200, Seif Lotfy wrote: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: * Sorting search results according to frequency/recency * Populating dashboards * Finding files/contacts/etc... that are used together * History browser * Associating locations to items (used at location X or Y) * scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have GNOME specific developments: * We already log everything that pushes into Gtk.RecentlyUsed. * For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. * We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. * Additionally, the team wrote several plugins for GNOME Shell [2][3][4] * Integration with telepathy-folks is currently under development. * Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. -- mailto:ak...@gmx.net | failed 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: Module Proposal: Zeitgeist
On Wed, Apr 18, 2012 at 10:24 AM, Milan Bouchet-Valat nalimi...@club.frwrote: Le mardi 17 avril 2012 à 22:47 +0200, Seif Lotfy a écrit : Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Preamble: It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: * Not enough integration with GNOME applications * Project hosting difficulties You didn't say anything about the places integration to the core desktop, i.e. the Shell and the Documents app. I think this is the key point. What's the status of the experimental Finding and Reminding view that was based on Zeitgeist[1] and of the Shell extension[2]? Have you discussed with designers about that recently? I'm all for adding Zeitgeist as a dependency, but the essential question is (and has been since the beginning) how to make the best use of it in the core desktop. IMHO that's where you can break the chicken-and-egg vicious cycle. My two cents 1: http://people.gnome.org/~federico/news-2011-02.html#zeitgeist-in-gnome-shell 2: https://extensions.gnome.org/extension/62/journal/ Hey Milan, As far as I know the designers could not find a place for Zeitgeist in the core apps. This is the reason why I made my work as an extension so people who feel like using it can try it out easily. There are 3 issues in discussion or in development where Zeitgeist integration is reaching a halt due to the uncertainty of where Zeitgeist stands: - Epiphany (Web): There has long been discussions on how to deploy Zeitgeist as a backend for Web. Web needed to rethink its history problem. It ended up with developing an SQLite based history backend. Right now we are discussing replacing this backend with Zeitgeist, since Zeitgeist can do everything the SQLite backend can. plus we can add new features to Web that make use of Zeitgeist's Full-Text-Search capabilities for searching via the uri bar. - Folks: I added some new properties to the individuals class in folks (currently in review). Now I could give more detail and allow the Contacts app to sort individuals by recency/frequency of interaction. The telepathy backend for this feature needs Zeitgeist. The Telepathy backend can provide even more info such as Show me all files sent to X or recevied from X (same goes for URIs). This feature was requested by Garrett LeSage from the GNOME Design team. - Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. As I see also there is some ideas going around for the searching via Shell. I agree that every application should be able to provide it search results to shell (aggregated search). I think Zeitgeist could fit in there nicely to sort the aggregated results globally according to recency or frequency. This is all I got honestly. Thanks Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Tue, 2012-04-17 at 22:47 +0200, Seif Lotfy wrote: snip We already have GNOME specific developments: * We already log everything that pushes into Gtk.RecentlyUsed. * For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. We already mentioned that this should instead be made into a better Gtk.RecentlyUsed. Applications shouldn't have to do the work twice. snip * Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] This needs to happen before any more applications integrate with Zeitgeist. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature Proposals vs new modules [was: Module Proposal: Zeitgeist]
Hi Andre, Thanks for the quick reply. I have some concern though that for framework authors, it's very hard to understand the new module proposal process. This might be slightly off the topic... so I understand if you would put this in another thread. New features get planned for GNOME 3.6. When it comes to implementing them, which is most probably after the feature proposal is over, how is it decided if a technology should be used or not if the proposal period is closed? How would it affect the developers if a library or a framework is blessed to be used in a core application? How will the user notice that? E.g: Empathy want to add sorting contract according to popularity? If the feature is not in the 3.6 feature plan [0], does this mean the feature should be postponed 6 months? If no, can the Empathy developers use a library or daemon that is not regarded as an external dependency for GNOME? What if an external dependency wants to add a dependency? I am not sure that rules that apply on UI visible proposals, should be applied on libraries and non-ui modules. Cheers Seif [0] https://live.gnome.org/ThreePointFive/Features/ On Wed, Apr 18, 2012 at 10:58 AM, Andre Klapper ak...@gmx.net wrote: Hi Seif, FYI we dropped the module proposals period and replaced it by a proposal period for systemwide features. See https://mail.gnome.org/archives/devel-announce-list/2012-March/msg5.htmlfor the GNOME 3.5 call. So the question would turn into Which (Zeitgeist-based) features could become part of GNOME 3.6 and what are the advantages for the GNOME system. As far as I see this is already answered by your section below, both by describing systemwide functionality provided by Zeitgeist and by listing several GNOME modules with existing or planned integration code. andre On Tue, 2012-04-17 at 22:47 +0200, Seif Lotfy wrote: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: * Sorting search results according to frequency/recency * Populating dashboards * Finding files/contacts/etc... that are used together * History browser * Associating locations to items (used at location X or Y) * scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have GNOME specific developments: * We already log everything that pushes into Gtk.RecentlyUsed. * For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. * We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. * Additionally, the team wrote several plugins for GNOME Shell [2][3][4] * Integration with telepathy-folks is currently under development. * Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Seif Lotfy s...@lotfy.com wrote: ... There are 3 issues in discussion or in development where Zeitgeist integration is reaching a halt due to the uncertainty of where Zeitgeist stands: Epiphany (Web): There has long been discussions on how to deploy Zeitgeist as a backend for Web. Web needed to rethink its history problem. It ended up with developing an SQLite based history backend. Right now we are discussing replacing this backend with Zeitgeist, since Zeitgeist can do everything the SQLite backend can. plus we can add new features to Web that make use of Zeitgeist's Full-Text-Search capabilities for searching via the uri bar. We don't have a design for browser history search in Web yet [1]. Folks: I added some new properties to the individuals class in folks (currently in review). Now I could give more detail and allow the Contacts app to sort individuals by recency/frequency of interaction. The telepathy backend for this feature needs Zeitgeist. The Telepathy backend can provide even more info such as Show me all files sent to X or recevied from X (same goes for URIs). This feature was requested by Garrett LeSage from the GNOME Design team. That was considered in the Contacts design process, but it was decided that it wasn't appropriate/useful. Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. As I see also there is some ideas going around for the searching via Shell. I agree that every application should be able to provide it search results to shell (aggregated search). I think Zeitgeist could fit in there nicely to sort the aggregated results globally according to recency or frequency. There are some designs in development for shell search [2], and these have implications for how we want search results to be returned within individual applications. I don't have the expertise to comment on which technologies are required to implement those. As mentioned previously in this thread, I'd expect to see a specific feature proposal for 3.6, rather than a module proposal. A new feature might require new dependencies, of course (which you might have to justify, I guess). You could certainly propose Clocks as a feature for 3.6... Allan [1] https://live.gnome.org/Design/Apps/Web#Tentative_Design [2] https://live.gnome.org/GnomeShell/Design/Whiteboards/Search ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Wed, Apr 18, 2012 at 11:35 PM, Allan Day allanp...@gmail.com wrote: Seif Lotfy s...@lotfy.com wrote: ... There are 3 issues in discussion or in development where Zeitgeist integration is reaching a halt due to the uncertainty of where Zeitgeist stands: Epiphany (Web): There has long been discussions on how to deploy Zeitgeist as a backend for Web. Web needed to rethink its history problem. It ended up with developing an SQLite based history backend. Right now we are discussing replacing this backend with Zeitgeist, since Zeitgeist can do everything the SQLite backend can. plus we can add new features to Web that make use of Zeitgeist's Full-Text-Search capabilities for searching via the uri bar. We don't have a design for browser history search in Web yet [1]. This has nothing to do with design honestly. This is a way to save history. Make it easier and more efficient for Web to store/retrieve history. How would that effect the UX? Folks: I added some new properties to the individuals class in folks (currently in review). Now I could give more detail and allow the Contacts app to sort individuals by recency/frequency of interaction. The telepathy backend for this feature needs Zeitgeist. The Telepathy backend can provide even more info such as Show me all files sent to X or recevied from X (same goes for URIs). This feature was requested by Garrett LeSage from the GNOME Design team. That was considered in the Contacts design process, but it was decided that it wasn't appropriate/useful. I am not challenging this decision but fwiw I sort my GTalk contacts via most popular. Which is something I think calculated via frequency of use/recently used. Does this mean having this option in the Folks library (which is something not UI or UX related) not allowed. Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? As I see also there is some ideas going around for the searching via Shell. I agree that every application should be able to provide it search results to shell (aggregated search). I think Zeitgeist could fit in there nicely to sort the aggregated results globally according to recency or frequency. There are some designs in development for shell search [2], and these have implications for how we want search results to be returned within individual applications. I don't have the expertise to comment on which technologies are required to implement those. As mentioned previously in this thread, I'd expect to see a specific feature proposal for 3.6, rather than a module proposal. A new feature might require new dependencies, of course (which you might have to justify, I guess). You could certainly propose Clocks as a feature for 3.6... I really would rather have the technologies I am allowed to use figured out before I continue with alarms. Currently Emily is doing some more designing. Allan [1] https://live.gnome.org/Design/Apps/Web#Tentative_Design [2] https://live.gnome.org/GnomeShell/Design/Whiteboards/Search ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
So let me try to take Web use cases that could use Zeitgeist: - The user wants to type in the location bar and have suggestions pop out while typing. - The user wants to blacklist some websites or all websites starting with porn from being stored in history - The user wants to disable history completely temporary - The user want to know where he downloaded a file from While I know all these features can be done without Zeitgeist. But why hack around if there is something there already, which could allow these ideas to be implemented with a few lines of code? Also I am aware that soon the design team wants to work on a Privacy feature. While privacy is much more than logging and encapsulates domain such as sharing. Imagine the user want to delete traces of his activities from the last 30 minutes, this includes logs from Web and maybe logs from Music. I think Zeitgeist sets up a good basis for manipulating and managing the application logs if applications choose to share with Zeitgeist its activities. What do you think? We already did initial work on this downstream for Ubuntu and Dawati and I think GNOME could leverage from that. I know these are all features that are not proposed for 3.6 but would it work if I proposed our Activity Log Manager for GNOME 3.6 as a feature... I guess not, since Zeitgeist is not the main mean for logging activities in GNOME. What do you think? Cheers Seif On Wed, Apr 18, 2012 at 11:43 PM, Seif Lotfy s...@lotfy.com wrote: On Wed, Apr 18, 2012 at 11:35 PM, Allan Day allanp...@gmail.com wrote: Seif Lotfy s...@lotfy.com wrote: ... There are 3 issues in discussion or in development where Zeitgeist integration is reaching a halt due to the uncertainty of where Zeitgeist stands: Epiphany (Web): There has long been discussions on how to deploy Zeitgeist as a backend for Web. Web needed to rethink its history problem. It ended up with developing an SQLite based history backend. Right now we are discussing replacing this backend with Zeitgeist, since Zeitgeist can do everything the SQLite backend can. plus we can add new features to Web that make use of Zeitgeist's Full-Text-Search capabilities for searching via the uri bar. We don't have a design for browser history search in Web yet [1]. This has nothing to do with design honestly. This is a way to save history. Make it easier and more efficient for Web to store/retrieve history. How would that effect the UX? Folks: I added some new properties to the individuals class in folks (currently in review). Now I could give more detail and allow the Contacts app to sort individuals by recency/frequency of interaction. The telepathy backend for this feature needs Zeitgeist. The Telepathy backend can provide even more info such as Show me all files sent to X or recevied from X (same goes for URIs). This feature was requested by Garrett LeSage from the GNOME Design team. That was considered in the Contacts design process, but it was decided that it wasn't appropriate/useful. I am not challenging this decision but fwiw I sort my GTalk contacts via most popular. Which is something I think calculated via frequency of use/recently used. Does this mean having this option in the Folks library (which is something not UI or UX related) not allowed. Clocks: The clocks app is designed by the GNOME designers. It is still more or less a prototype I am working on alongside Emily Gonyer. We wanted to make use of Zeitgeist in storing Alarms as a type of scheduled event, it sounds like shoehorning but it is not. I am just hesitant because I myself as a GNOME member do not want to use a technology or force integrate it without GNOME agreeing of the usage of Zeitgeist. It might help for you to elaborate why Zeitgeist is needed there. Clocks is intended to be a really simple application. We need to be able to store Alarms. And those alarms should still work while the clocks application is closed. For that we need a central storage for the scheduled event which is the alarm, to notify all subscribers including Shell that an alarm went off. Same would go for timers. What do you think? As I see also there is some ideas going around for the searching via Shell. I agree that every application should be able to provide it search results to shell (aggregated search). I think Zeitgeist could fit in there nicely to sort the aggregated results globally according to recency or frequency. There are some designs in development for shell search [2], and these have implications for how we want search results to be returned within individual applications. I don't have the expertise to comment on which technologies are required to implement those. As mentioned previously in this thread, I'd expect to see a specific feature proposal for 3.6, rather than a module proposal. A new feature might require new dependencies, of course (which you
Module Proposal: Zeitgeist
*Purpose: *Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. *Preamble: *It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: - Not enough integration with GNOME applications - Project hosting difficulties - Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: - Sorting search results according to frequency/recency - Populating dashboards - Finding files/contacts/etc... that are used together - History browser - Associating locations to items (used at location X or Y) - scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have *GNOME specific developments*: - We already log everything that pushes into Gtk.RecentlyUsed. - For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. - We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. - Additionally, the team wrote several plugins for GNOME Shell [2][3][4] - Integration with telepathy-folks is currently under development. - Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. We have moved to freedesktop.org so we can play nicely with GNOME, KDE, Ubuntu as well as others. [7] Since we are not a GNOME dependency some projects hesitate to integrate with us. It is a chicken and egg problem. Applications don't want to depend on us since we are not GNOME upstream (thus only soft-dependencies) and GNOME hesitates to accept Zeitgeist since no application fully depends on it. For example: We want to use Zeitgeist in GNOME Clocks will to store alarms as scheduled activities. However we are not sure if we can do that without Zeitgeist being an external dependency. Another example, Epiphany integration: Zeitgeist could take over storing Epiphany history. However due to the uncertain state of Zeitgeist in GNOME we can not move on. I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd be happy to add support for it in Epiphany. *Some interesting facts about Zeitgeist: * - It is a dependency for Ubuntu Unity - Many application specific plugins that make use of what Zeitgeist has got to offer. - Integration into Phonon, the KDE multimedia framework and various deployments within KDE - Deploying in Dawati [0] - Paid dedicated developers - Previously ported from Python to Vala without breaking API *Proposal to become a blessed dependency *With this appliation I would like to address the possibility of accepting Zeitgeist as a blessed dependency. *Dependencies*: - Vala - Sqlite - Xapian (Soft) - python-rdflib (only for compiling the ontologies) *Resource usage: * - Bug tracker: http://bugs.freedesktop.org/ - VCS: http://cgit.freedesktop.org/zeitgeist/ *Other notes: *What most people think of as Zeitgeist is split in two processes zeitgeist-daemon and zeitgeist-datahub. The daemon does not do any active monitoring for events, it only manages the log database and exposes a DBus interface for inserting, deleting, querying events, and monitoring for changes. The datahub monitors the system and pushes events into the daemon. This architecture makes the datahub expendable if we one day move to an architecture where apps themselves (or something else) push events into Zeitgeist. Indeed it's already the case that we have plugins for some apps that makes them push events into the daemon. [0] http://dawati.org/ [1] http://seilo.geekyogre.com/2011/11/gedit-dash-0-1/ [2] https://extensions.gnome.org/extension/62/journal/ [3] https://extensions.gnome.org/extension/33/jump-lists/ [4]
Re: Module Proposal: Zeitgeist
+1 for me. I think there is some great potential for interesting features in GNOME. I've always been a big fan of the mapping of documents on a calendar so I know what I was working on a particular day. As a marketing guy, I'd like us to beat our competition with unique features that can't be seen on other platforms. On Tue, Apr 17, 2012 at 1:47 PM, Seif Lotfy s...@lotfy.com wrote: *Purpose: *Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. *Preamble: *It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: - Not enough integration with GNOME applications - Project hosting difficulties - Immaturity of the project. Zeitgeist is not meant for searching through your files and folders, but rather as a log for user activities. This can be used for: - Sorting search results according to frequency/recency - Populating dashboards - Finding files/contacts/etc... that are used together - History browser - Associating locations to items (used at location X or Y) - scheduling activities (files/contacts/et...) can be set (See Task pooper) People have expressed interest in using it within GNOME, we want to help and make it happen. We think all these use cases could be address. We already have *GNOME specific developments*: - We already log everything that pushes into Gtk.RecentlyUsed. - For better logging we have Totem, Rhythmbox, and gedit deploying loggers as a soft-dependency in the form of plugins. - We worked with gedit and some GNOME designers to develop the Dashboard plugin [1] to address the empty slate problem. - Additionally, the team wrote several plugins for GNOME Shell [2][3][4] - Integration with telepathy-folks is currently under development. - Discussion about a possible Gtk Recenet Manager revamp with an optional Zeitgeist backend. [5] Another deployment in development is a feature that we think would enrich the developer story for folks, which is giving folks the ability to actually provide developers with some interaction details for each individual. [6] This is under development and hopefully can be merged soon. We also provide a logger for Telepathy as part of the zeitgeist-datasources package. It will soon be shipped directly with Telepathy-Logger as a soft-dependency. We have moved to freedesktop.org so we can play nicely with GNOME, KDE, Ubuntu as well as others. [7] Since we are not a GNOME dependency some projects hesitate to integrate with us. It is a chicken and egg problem. Applications don't want to depend on us since we are not GNOME upstream (thus only soft-dependencies) and GNOME hesitates to accept Zeitgeist since no application fully depends on it. For example: We want to use Zeitgeist in GNOME Clocks will to store alarms as scheduled activities. However we are not sure if we can do that without Zeitgeist being an external dependency. Another example, Epiphany integration: Zeitgeist could take over storing Epiphany history. However due to the uncertain state of Zeitgeist in GNOME we can not move on. I would like to quote Xan Lopez: if GNOME decides to use it throughout I'd be happy to add support for it in Epiphany. *Some interesting facts about Zeitgeist: * - It is a dependency for Ubuntu Unity - Many application specific plugins that make use of what Zeitgeist has got to offer. - Integration into Phonon, the KDE multimedia framework and various deployments within KDE - Deploying in Dawati [0] - Paid dedicated developers - Previously ported from Python to Vala without breaking API *Proposal to become a blessed dependency *With this appliation I would like to address the possibility of accepting Zeitgeist as a blessed dependency. *Dependencies*: - Vala - Sqlite - Xapian (Soft) - python-rdflib (only for compiling the ontologies) *Resource usage: * - Bug tracker: http://bugs.freedesktop.org/ - VCS: http://cgit.freedesktop.org/zeitgeist/ *Other notes: *What most people think of as Zeitgeist is split in two processes zeitgeist-daemon and zeitgeist-datahub. The daemon does not do any active monitoring for events, it only manages the log database and exposes a DBus interface for inserting, deleting, querying events, and monitoring for changes. The datahub monitors the system and pushes events
Re: Module Proposal: Zeitgeist
Le lundi 03 mai 2010 à 00:37 +0200, Seif Lotfy a écrit : snip So in case Zeitgeist can not be a GNOME module because of its development infrastructure, we hereby withdraw our proposal of Zeitgeist being a GNOME module and propose it as an external dependency for GNOME Activity Journal, so it will always have a close relation to GNOME. Sounds a sane solution to me, since you seem to head towards KDE support too. Though, having a git clone repository somewhere would be nice for people willing to help on both sides. It's likely that GNOME contributors will want to improve the engine, and not only the GUI. What about a clone on git.gnome.org, just like the system-tools-backends-clone one? Would there be a way in Launchpad to merge git branches by importing them to bzr? Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Dear GNOMErs, GNOME Activity Journal is being moved to the GNOME Development Infrastructure... However after some heavy discussion within the Zeitgeist team, we decided to keep Zeitgeist in Launchpad, and not move it to the GNOME Development Infrastructure. While Zeitgeist has been developed for GNOME it doesn't heavily depend on any GNOME modules. Thus Zeitgeist could also gain adoption outside the GNOME ecosystem if it remains slightly independent, which would only serve to strengthen its reliability and usefulness on the GNOME desktop too. Our current workflow and teamwork has adopted perfectly to Launchpad. We don't intend to move to Git now or in the foreseen future, since it will disturb our organizational and development habits. So in case Zeitgeist can not be a GNOME module because of its development infrastructure, we hereby withdraw our proposal of Zeitgeist being a GNOME module and propose it as an external dependency for GNOME Activity Journal, so it will always have a close relation to GNOME. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
i really feel sorry for that decision, i would have loved to see zeitgeist as a growing project inside the gnome infrastructure. furthermore i hope that the gnome community does not loose interest in this project, even if such a decision makes it harder to track whats going on. at last i hope, that you guys at least consider making zeitgeist a freedesktop.org project. daniel On Mo, 2010-05-03 at 00:37 +0200, Seif Lotfy wrote: Dear GNOMErs, GNOME Activity Journal is being moved to the GNOME Development Infrastructure... However after some heavy discussion within the Zeitgeist team, we decided to keep Zeitgeist in Launchpad, and not move it to the GNOME Development Infrastructure. While Zeitgeist has been developed for GNOME it doesn't heavily depend on any GNOME modules. Thus Zeitgeist could also gain adoption outside the GNOME ecosystem if it remains slightly independent, which would only serve to strengthen its reliability and usefulness on the GNOME desktop too. Our current workflow and teamwork has adopted perfectly to Launchpad. We don't intend to move to Git now or in the foreseen future, since it will disturb our organizational and development habits. So in case Zeitgeist can not be a GNOME module because of its development infrastructure, we hereby withdraw our proposal of Zeitgeist being a GNOME module and propose it as an external dependency for GNOME Activity Journal, so it will always have a close relation to GNOME. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: However we do want to keep our development branches in bzr+launchpad. That sounds reasonable. The Java bindings have been using bzr since before GNOME moved to svn. Needless to say we kept using it, and likewise skipped the subsequent move to git. We use Bugzilla, but that again is because a) our usage of it predates Launchpad, and b) we don't use [nor does anyone need to] use Launchpad for branch management [we don't use Bugzilla for patch workflow either; we discuss patches on IRC and on our mailing lists]. I'd be tempted to start using Launchpad for code reviews — they're getting pretty sophisticated — but the whole point of decentralized VCS is disconnected operation and having to have an active internet connection to get to some centralized website in order to follow through workflow is a non-starter for most of us. AfC Sydney signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Mon, Apr 26, 2010 at 2:01 AM, Cody Russell brats...@gnome.org wrote: Eh, github's pull requests are not really the same as a code review system. At least last time I looked at it. You do a pull request and the person you're requesting basically just gets a message that says, Hey dude, check out my awesome code! There isn't a nice UI for doing the code review, with diffs that can be commented on and whatever. Uhm, you're supposed to review commits. You get a pull request (or just stumble upon a fork of particular interest) and go to view related commits. Each commit allows you to review each and every line of code. It even seems that's where gitorious got their UI from. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, 2010-04-25 at 19:01 -0500, Cody Russell wrote: On Sun, 2010-04-25 at 22:44 +0200, Patryk Zawadzki wrote: On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Actually this is not true. GitHub lets you review any commit and the usual workflow is fork → commit → request pull → get review. Eh, github's pull requests are not really the same as a code review system. At least last time I looked at it. You do a pull request and the person you're requesting basically just gets a message that says, Hey dude, check out my awesome code! There isn't a nice UI for doing the code review, with diffs that can be commented on and whatever. I cannot say if it is nice but github have since some time option to comment code/diffs. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: I think you can: * use bzr-git to push your Launchpad trunk to GNOME git * setup an import of the git branch and make it trunk launchpad just imports git master, right? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Mon, 2010-04-26 at 13:51 +0200, Rodrigo Moya wrote: On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: I think you can: * use bzr-git to push your Launchpad trunk to GNOME git * setup an import of the git branch and make it trunk launchpad just imports git master, right? No. Launchpad import any git/bzr/hg branch Launchpad only import SVN/CVS trunk. -- __C U R T I S C. H O V E Y___ Guilty of stealing everything I am. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le lundi 26 avril 2010 à 17:18:31% (+1000), Andrew Cowie a écrit: but the whole point of decentralized VCS is disconnected operation and having to have an active internet connection to get to some centralized website in order to follow through workflow is a non-starter for most of us. I agree, FWIW. I prefer dealing with patch review through simple email for that reason. It's so much easier to just do the review offline. It would be interesting to find a way to make these tools -- bugzilla or whatever patch review system -- be interoperable with email. If I could just get patches attached to GNOME bugzilla bugs in my email, reply to those via email and have those properly appear in bugzilla comments, that would be great for me. Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
2010/4/26 Dodji Seketeli do...@seketeli.org: It would be interesting to find a way to make these tools -- bugzilla or whatever patch review system -- be interoperable with email. Launchpad supports answering to merge requests by mail (as well as managing bugs, etc). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le lundi 26 avril 2010 à 21:24:19% (+0200), Siegfried-Angel Gevatter Pujals a écrit: 2010/4/26 Dodji Seketeli do...@seketeli.org: It would be interesting to find a way to make these tools -- bugzilla or whatever patch review system -- be interoperable with email. Launchpad supports answering to merge requests by mail (as well as managing bugs, etc). I guess It would be useful that GNOME bugzilla supports this too. Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Fri, 2010-04-23 at 18:59 -0400, Owen Taylor wrote: On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: ... I think Launchpad + BZR and GNOME + git can interoperate fine. I think you can: * use bzr-git to push your Launchpad trunk to GNOME git * setup an import of the git branch and make it trunk * Use launchpad for development, translations, and reviews * Use bzr-git to commit your approved branches to GNOME git. ... I think the question is, is this OK for a GNOME module? The main point of requiring use of GNOME infrastructure for GNOME modules, as I see it, is that anybody in the GNOME community can immediately jump in, start helping out, and start contributing to the module. And also, that people working on your module can seamlessly move over to working on other parts of GNOME. It's being part of the GNOME community. If the Zeitgeist community is centered around Launchpad and bzr and wants changes submitted as launchpad branches, but it happens that you can check it out of GNOME git, that's not being part of the GNOME community. I think we are talking about slightly different issues here. I agreed that gnome projects should use git.gnome.org as their master, and that contributors may use git to do their development. My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. A contributor will contact the Zeitgeist's developers when he has a branch he wants to merge. I assume this works much like it does for most GNOME projects, via email or comment on a bug. The core developers can submit the proposed merge to launchpad. The core developers are responsible for doing merges (which is the case for more projects). If a contributors has an OpenID, he could submit merge proposal himself through, but he would have to have prior experience to know this. This is not really different from any other GNOME project that has its own culture of how to propose a merge. (A secondary point is definitely being part of our translation infrastructure so that the translators can make sure that GNOME is properly translated into their languages without having to join and participate in some different translation community.) Launchpad is not a final solution to translations. It merely lowers the barrier for translators to participate. Translations can and will continue though direct commits to the master branch in git.gnome.org. The project can enable series syncing in Launchpad so that latest templates and messages (Actually, the development series already is setup) The Zeitgeist can designate a branch automatically the updated po dir that can me merged into git.gnome.org using git or bzr (and all the history is preserved) PS. I think part of the misconception here is that many people think of Launchpad as a project hosting services. It is more like a community hosting services because no one has total ownership of a project. The Ubuntu community use the project for source package tracking and translations. The project name is place where communities collaborate. -- __C U R T I S C. H O V E Y___ Guilty of stealing everything I am. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On 24 April 2010 11:18, Johannes Schmid j...@jsschmid.de wrote: Hi! No one ever said that we wont accept git branches. Anything submitted as a patch or git branch will merge just as easy as any bzr-based contribution. The only thing that may be more inconvenient is the hack directly in trunk-workflow that is inherent to the monolithic VCSs of old, but not so much of modern DVCSs. git is meant for using branches but not necessarily for creating a public branch when you fix a typo. People create patches against master in bugzilla usually even if we could use pull-requests possibly but this hasn't been used that. So making this inconvenient is breaking the workflow. I indeed meant that bog standard patches would still be easy to handle (if they are created against a recent git or bzr checkout). What I mean with the hack directly in trunk-workflow is the typical CVS/SVN workflow where the core devs do rapid change/commit cycles directly in trunk. But anyway, as you also point out (if I understand you correctly), if ZG ends up as an external dependency it should stay external to the Gnome infrastructure. And the fact also remains that Gnome is not the only project that has interest in ZG since KDE and the mobile community has shown interest as well. owen: However, the external dependency mechanism is really meant to be there for something that is already out there, that already has a stable version that we can depend upon and that provides the features we need, and that has a development community and process that are going to run independent of GNOME. It's not meant for something that is being cooperatively developed in tandem with GNOME features. I see. I may have been a bit preoccupied when I read it the first time :-) -- Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Actually this is not true. GitHub lets you review any commit and the usual workflow is fork → commit → request pull → get review. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, 25.04.10 22:44, Patryk Zawadzki (pat...@pld-linux.org) wrote: On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Actually this is not true. GitHub lets you review any commit and the usual workflow is fork → commit → request pull → get review. Gitorious has that too apparently: http://blog.gitorious.org/2009/11/06/awesome-code-review/ BTW: What happened to those plans to run our own gitorious instance on gnome.org or have a gnome subdomain on the real gitorious.org the way qt has? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, 2010-04-25 at 22:44 +0200, Patryk Zawadzki wrote: On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Actually this is not true. GitHub lets you review any commit and the usual workflow is fork → commit → request pull → get review. Eh, github's pull requests are not really the same as a code review system. At least last time I looked at it. You do a pull request and the person you're requesting basically just gets a message that says, Hey dude, check out my awesome code! There isn't a nice UI for doing the code review, with diffs that can be commented on and whatever. Compare the link Lennart posted about gitorious, or compare the Launchpad merge request system, to this: http://github.com/guides/pull-requests / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 25, 2010 at 10:59 AM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Official is an interesting word, but Splinter is integrated directly in GNOME bugzilla and supports line-by-line code review. http://blog.fishsoup.net/2009/09/23/splinter-patch-review/ Combined with git-bz, patch submission and review becomes much easier. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On 24 April 2010 00:59, Owen Taylor otay...@redhat.com wrote: On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. I think Launchpad + BZR and GNOME + git can interoperate fine. I think you can: * use bzr-git to push your Launchpad trunk to GNOME git * setup an import of the git branch and make it trunk * Use launchpad for development, translations, and reviews * Use bzr-git to commit your approved branches to GNOME git. You can request a rescan of GNOME git (takes about 5 minutes) to get the changes back to Launchpad. If you need assistance, I can help. If I cannot help, I am sure someone from the launchpad-code team can explain the workflow. I think the question is, is this OK for a GNOME module? The main point of requiring use of GNOME infrastructure for GNOME modules, as I see it, is that anybody in the GNOME community can immediately jump in, start helping out, and start contributing to the module. And also, that people working on your module can seamlessly move over to working on other parts of GNOME. It's being part of the GNOME community. If the Zeitgeist community is centered around Launchpad and bzr and wants changes submitted as launchpad branches SNIP No one ever said that we wont accept git branches. Anything submitted as a patch or git branch will merge just as easy as any bzr-based contribution. The only thing that may be more inconvenient is the hack directly in trunk-workflow that is inherent to the monolithic VCSs of old, but not so much of modern DVCSs. But anyway, as you also point out (if I understand you correctly), if ZG ends up as an external dependency it should stay external to the Gnome infrastructure. And the fact also remains that Gnome is not the only project that has interest in ZG since KDE and the mobile community has shown interest as well. -- Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi! No one ever said that we wont accept git branches. Anything submitted as a patch or git branch will merge just as easy as any bzr-based contribution. The only thing that may be more inconvenient is the hack directly in trunk-workflow that is inherent to the monolithic VCSs of old, but not so much of modern DVCSs. git is meant for using branches but not necessarily for creating a public branch when you fix a typo. People create patches against master in bugzilla usually even if we could use pull-requests possibly but this hasn't been used that. So making this inconvenient is breaking the workflow. But anyway, as you also point out (if I understand you correctly), if ZG ends up as an external dependency it should stay external to the Gnome infrastructure. And the fact also remains that Gnome is not the only project that has interest in ZG since KDE and the mobile community has shown interest as well. owen: However, the external dependency mechanism is really meant to be there for something that is already out there, that already has a stable version that we can depend upon and that provides the features we need, and that has a development community and process that are going to run independent of GNOME. It's not meant for something that is being cooperatively developed in tandem with GNOME features. You turning his words round. Read the last sentence... Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
There is the further issue of translation. The Bulgarian team had prepared a translation to Zeitgeist available here: http://fsa-bg.org/project/gtp/browser/gnome/gnome3/zeitgeist.trunk.bg.po We could not import it to Launchpad because a team member there had locked the translation. (and we had another team member cooperating with us who could not help, it seems locking in Launchpad is really exclusive). I would really expect a module this central to GNOME to be administered using the usual GNOME infrastructure. Otherwise there is pressure put on long time GNOME contributors and our work is made more difficult. Kind regards: al_shopov ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Mikkel, On Thu 22 Apr 2010 21:40, Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com writes: Here's what we do. We set a series of milestones and target bugs and blueprints to these milestones. We also attach branches (not patches) to bugs and blueprints. When a linked branch is ready to merge into another branch (trunk or other) we add a merge request, which enables the review system. It's not as slick as launchpad, but have you tried bgo's splinter? One can push git branches to bugzilla, and review the patches on the web, with a quite acceptable interface. Just a data point :) We create sub teams and sub projects that all have different rights and responsibilities. So basically we use pretty much all aspects of a modern project hosting solution. Bugzilla is just a bug tracker. Obviously you have to do what's best for you, but I have found it best to rely on a more flat technical rights division -- for example, either you're in the project or you're out, and most people that want to should be in. Rights and responsibilities can in many cases be managed better on the social level, with trust. This also allows people to migrate to different areas of resposibility over time. YMMV, of course. Happy hacking, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
2010/4/23 Александър Шопов li...@kambanaria.org: There is the further issue of translation. We already agreed that translations can be moved to GNOME infrastructure. I've just committed the translation, btw. Thanks! -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. I think Launchpad + BZR and GNOME + git can interoperate fine. I think you can: * use bzr-git to push your Launchpad trunk to GNOME git * setup an import of the git branch and make it trunk * Use launchpad for development, translations, and reviews * Use bzr-git to commit your approved branches to GNOME git. You can request a rescan of GNOME git (takes about 5 minutes) to get the changes back to Launchpad. If you need assistance, I can help. If I cannot help, I am sure someone from the launchpad-code team can explain the workflow. -- __C U R T I S C. H O V E Y___ Guilty of stealing everything I am. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. I think Launchpad + BZR and GNOME + git can interoperate fine. I think you can: * use bzr-git to push your Launchpad trunk to GNOME git * setup an import of the git branch and make it trunk * Use launchpad for development, translations, and reviews * Use bzr-git to commit your approved branches to GNOME git. You can request a rescan of GNOME git (takes about 5 minutes) to get the changes back to Launchpad. If you need assistance, I can help. If I cannot help, I am sure someone from the launchpad-code team can explain the workflow. I think the question is, is this OK for a GNOME module? The main point of requiring use of GNOME infrastructure for GNOME modules, as I see it, is that anybody in the GNOME community can immediately jump in, start helping out, and start contributing to the module. And also, that people working on your module can seamlessly move over to working on other parts of GNOME. It's being part of the GNOME community. If the Zeitgeist community is centered around Launchpad and bzr and wants changes submitted as launchpad branches, but it happens that you can check it out of GNOME git, that's not being part of the GNOME community. (A secondary point is definitely being part of our translation infrastructure so that the translators can make sure that GNOME is properly translated into their languages without having to join and participate in some different translation community.) As for the external dependency question - certainly there are other components like GStreamer and Clutter that are external dependencies despite being closely tied in with the GNOME platform. However, the external dependency mechanism is really meant to be there for something that is already out there, that already has a stable version that we can depend upon and that provides the features we need, and that has a development community and process that are going to run independent of GNOME. It's not meant for something that is being cooperatively developed in tandem with GNOME features. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 24, 2010 at 4:29 AM, Owen Taylor otay...@redhat.com wrote: On Fri, 2010-04-23 at 16:52 -0400, Curtis Hovey wrote: I think Launchpad + BZR and GNOME + git can interoperate fine. [snip] I think the question is, is this OK for a GNOME module? The main point of requiring use of GNOME infrastructure for GNOME modules, as I see it, is that anybody in the GNOME community can immediately jump in, start helping out, and start contributing to the module. And also, that people working on your module can seamlessly move over to working on other parts of GNOME. It's being part of the GNOME community. [snip excellent points] However, the external dependency mechanism is really meant to be there for something that is already out there, that already has a stable version that we can depend upon and that provides the features we need, and that has a development community and process that are going to run independent of GNOME. It's not meant for something that is being cooperatively developed in tandem with GNOME features. I was ambivalent to this discussion, but Owen has swayed me and I completely agree with him now. I think this discussion has been trying to follow the letter of the rules, but the intent has been forgotten. One of the intents of the rules is to prevent fragmentation of development, the codebase, and the community. Another is to allow people (and distributors) to only need to follow one source of information (the GNOME infrastructure) to work with upstream. This is how GNOME's workflow is organised. If Zeitgeist goes outside this; then it disrupts everyone's workflow whenever they need to interact with Zeitgeist. The external deps rule was added out of necessity; some projects are more than just GNOME-centric; and belong on freedesktop, or a completely/mostly DE/OS-agnostic infrastructure such as sourceforge, github, code.google.com, launchpad, etc. We cannot say Python must use GNOME infrastructure before python apps are allowed in the GNOME stack; but we *can* say that for Vala because it was developed specifically for use with the Glib/GNOME stack. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On 22 April 2010 00:01, Johannes Schmid j...@jsschmid.de wrote: Hi! Resource usage: Bug tracker: http://bugs.launchpad.net/zeitgeist VCS: http://code.launchpad.net/zeitgeist Releases: http://launchpad.net/zeitgeist/+download According to http://live.gnome.org/ReleasePlanning/ModuleProposing: Use of GNOME resources: Modules must use GNOME FTP for releases. Modules ought to use GNOME Bugzilla and GNOME Git (there had better be a very good reason for not doing so, such as freedesktop.org hosted libraries designed to be used by both GNOME and KDE). What are your plans? Same probably applies for i18n (damned-lies). We don't have any concrete plans. However moving our tarballs to GNOME FTP should pose no problem at all, likewise for i18n. Since we are talking daemons here i18n is not a big part of the project. As for VCS and bug tracking it'll be quite a lot more work on our part if we should move. I don't think anyone in the team is directly opposed to the idea, but it's more the fact that it would be a major inconvenience. We make heavy use of Launchpad's branc/review features and integration with blueprints and bugs. Of course we can replace this with a hand held combination of bugzilla and wikipages, but it would be a major change in our workflow. Perhaps an unholy alliance of bzr-git and Launchpad's git-import feature can make all parts happy (at least vcs-wise)? I will take a look at this when I have the time. -- Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi! (seems like the initial reply wasn't sent to the ML) According to http://live.gnome.org/ReleasePlanning/ModuleProposing: Use of GNOME resources: Modules must use GNOME FTP for releases. Modules ought to use GNOME Bugzilla and GNOME Git (there had better be a very good reason for not doing so, such as freedesktop.org hosted libraries designed to be used by both GNOME and KDE). What are your plans? Same probably applies for i18n (damned-lies). We don't have any concrete plans. However moving our tarballs to GNOME FTP should pose no problem at all, likewise for i18n. Since we are talking daemons here i18n is not a big part of the project. I18n more or less directly depends on having the module in git (as damned-lies gets the status from git and will be able to commit directly to git in the not-to-far-away future. As for VCS and bug tracking it'll be quite a lot more work on our part if we should move. I don't think anyone in the team is directly opposed to the idea, but it's more the fact that it would be a major inconvenience. We make heavy use of Launchpad's branc/review features and integration with blueprints and bugs. Of course we can replace this with a hand held combination of bugzilla and wikipages, but it would be a major change in our workflow. I of course see your point that it courses some inconvenience and I wouldn't want to force you to do this migration tommorow but in the end, people will try to report GNOME bugs in bugzilla. I kind of looked on the amount of work that would need to be done and saw 12 bugs and 4 blueprints which is really an amount that can easily be handled manually (copypaste into bugzilla). I would rather do such a migration sooner that later because once your bug database fills up, things will get more difficult. If it's just to get this 16 items migrated I will happily volunteer... Perhaps an unholy alliance of bzr-git and Launchpad's git-import feature can make all parts happy (at least vcs-wise)? I will take a look at this when I have the time. I think you should rather see that the other way round - track your git.gnome.org stuff using bzr if you are more familiar with it but keep the real code in git. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Qua, 2010-04-21 às 22:41 +0200, Mikkel Kamstrup Erlandsen escreveu: Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Target: desktop What's the plan to integrate zeitgeist with gnome-shell and other applications ? I mean totem, nautilus, brasero, empathy etc... Also there's a plan to rewrite some API in C so other applications can use zeitgeist API ? Or we are just suppose to interact with zeigeist via dbus ? Cheers Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 07:15 +, j...@jsschmid.de wrote: We don't have any concrete plans. However moving our tarballs to GNOME FTP should pose no problem at all, likewise for i18n. Since we are talking daemons here i18n is not a big part of the project. As for VCS and bug tracking it'll be quite a lot more work on our part if we should move. I don't think anyone in the team is directly opposed to the idea, but it's more the fact that it would be a major inconvenience. We make heavy use of Launchpad's branc/review features and integration with blueprints and bugs. Of course we can replace this with a hand held combination of bugzilla and wikipages, but it would be a major change in our workflow. For something that intends to be such a major part of GNOME, not using GNOME's git and bugzilla is a huge problem. Resisting that wouldn't make people optimistic about things in future. I can't believe that it's that big a deal for Zeitgeist, compared with what you'd gain when you need to work with a much larger set of developers, testers, and users. It's worth adapting, please, because being in the GNOME Desktop is more than just getting a stamp of approval. -- 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: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 12:03 +0200, Murray Cumming wrote: On Thu, 2010-04-22 at 07:15 +, j...@jsschmid.de wrote: We don't have any concrete plans. However moving our tarballs to GNOME FTP should pose no problem at all, likewise for i18n. Since we are talking daemons here i18n is not a big part of the project. As for VCS and bug tracking it'll be quite a lot more work on our part if we should move. I don't think anyone in the team is directly opposed to the idea, but it's more the fact that it would be a major inconvenience. We make heavy use of Launchpad's branc/review features and integration with blueprints and bugs. Of course we can replace this with a hand held combination of bugzilla and wikipages, but it would be a major change in our workflow. For something that intends to be such a major part of GNOME, not using GNOME's git and bugzilla is a huge problem. Resisting that wouldn't make people optimistic about things in future. I can't believe that it's that big a deal for Zeitgeist, compared with what you'd gain when you need to work with a much larger set of developers, testers, and users. It's worth adapting, please, because being in the GNOME Desktop is more than just getting a stamp of approval. Completely agreed, though I'll be the devil's advocate, and mention that it's pretty complicated for students in the SoC (where Zeitgeist started) to get 1) git accounts 2) get bugzilla modules created. I wish there was a more integrated solution, or even a an easier way to create modules within a separate root from the rest of GNOME if we don't want to trust the students blindly at the start. Hopefully the new admin would sort that kind of problems out. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 08:10 +0200, Mikkel Kamstrup Erlandsen wrote: As for VCS and bug tracking it'll be quite a lot more work on our part if we should move. I don't think anyone in the team is directly opposed to the idea, but it's more the fact that it would be a major inconvenience. We make heavy use of Launchpad's branc/review features and integration with blueprints and bugs. Of course we can replace this with a hand held combination of bugzilla and wikipages, but it would be a major change in our workflow. I do the same for couchdb-glib and evolution-couchdb: the code is in GNOME Git, and imported in Launchpad, so you still can branch, propose stuff for reviewing, and then, when branches are accepted, you just merge it to GNOME Git (I do it by hand, because I haven't had much time to look at bzr-git, but it should be possible, I think, to just merge from the bzr branch to GNOME Git). Only problem I've found doing so is that launchpad only imports Git master, so it doesn't work for Git branches, if you use them ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 07:15 +, j...@jsschmid.de wrote: Perhaps an unholy alliance of bzr-git and Launchpad's git-import feature can make all parts happy (at least vcs-wise)? I will take a look at this when I have the time. I think you should rather see that the other way round - track your git.gnome.org stuff using bzr if you are more familiar with it but keep the real code in git. I think that's exactly what Mikkel was suggesting. Storing the code in git.gnome.org, but then using Launchpad's git-import to import things back to bzr branches in Launchpad so that all the developers can continue to do their work the way they're familiar with. / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. Cheers Seif On Thu, Apr 22, 2010 at 6:46 PM, Cody Russell brats...@gnome.org wrote: On Thu, 2010-04-22 at 07:15 +, j...@jsschmid.de wrote: Perhaps an unholy alliance of bzr-git and Launchpad's git-import feature can make all parts happy (at least vcs-wise)? I will take a look at this when I have the time. I think you should rather see that the other way round - track your git.gnome.org stuff using bzr if you are more familiar with it but keep the real code in git. I think that's exactly what Mikkel was suggesting. Storing the code in git.gnome.org, but then using Launchpad's git-import to import things back to bzr branches in Launchpad so that all the developers can continue to do their work the way they're familiar with. / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi! Am Donnerstag, den 22.04.2010, 19:01 +0200 schrieb Seif Lotfy: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. Why making this so utterly complicated? Is there some *specific* thing that makes your workflow based on launchpad? To be honest, I looked at the launchpad pages and compared to most other projects there are really few bugs und blueprints that would need to be moved to GNOME bugzilla (or maybe the wiki). BTW; this workflow will be horrible for translators. As said before, if you use git-bzr for your internal workflow or whatever, this is no problem, but not for public development. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. In that case you would have to propose launchpad as external dependency but I doubt this would make adaption any better. I would really like you to simple move over to GNOME infrastructure and pass this thread over to technical discussion. Thanks and regards, Johannes Cheers Seif On Thu, Apr 22, 2010 at 6:46 PM, Cody Russell brats...@gnome.org wrote: On Thu, 2010-04-22 at 07:15 +, j...@jsschmid.de wrote: Perhaps an unholy alliance of bzr-git and Launchpad's git-import feature can make all parts happy (at least vcs-wise)? I will take a look at this when I have the time. I think you should rather see that the other way round - track your git.gnome.org stuff using bzr if you are more familiar with it but keep the real code in git. I think that's exactly what Mikkel was suggesting. Storing the code in git.gnome.org, but then using Launchpad's git-import to import things back to bzr branches in Launchpad so that all the developers can continue to do their work the way they're familiar with. / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
2010/4/22 Johannes Schmid j...@jsschmid.de: BTW; this workflow will be horrible for translators. Could you please elaborate on that? -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Siegfried-Angel Gevatter Pujals wrote: 2010/4/22 Johannes Schmid j...@jsschmid.de: BTW; this workflow will be horrible for translators. Could you please elaborate on that? We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release., but release team is too late for translators. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. You could also close bug acceptance on the launchpad side, and move them to GNOME bugzilla when you have few enough to do it by hand. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. The desktop-neutral parts could probably move to fd.o if that's a concern. The point is that if you want zeitgeist in the GNOME desktop, it needs to use GNOME infrastructure. Because we like our workflow isn't a good enough reason to use 3rd-party providers (which I'm sure is a fine one). The project might as well be on sourceforge, or google code, it wouldn't change that problem. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. In such case, should not it be a freedesktop project and be proposed as an external dependency for the Activity Journal? Regards, -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 22, 2010 at 10:34 AM, Germán Póo-Caamaño g...@gnome.org wrote: On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. In such case, should not it be a freedesktop project and be proposed as an external dependency for the Activity Journal? The Activity Journal is in Launchpad and would have the same issues as we've been discussing (except moreso due to translator requirements). Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
I wrote: 2010/4/22 Johannes Schmid j...@jsschmid.de: BTW; this workflow will be horrible for translators. Could you please elaborate on that? We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release., but release team is too late for translators. s/release team/release time/, of course. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, 2010-04-22 at 10:37 -0700, Sandy Armstrong wrote: In such case, should not it be a freedesktop project and be proposed as an external dependency for the Activity Journal? The Activity Journal is in Launchpad and would have the same issues as we've been discussing (except moreso due to translator requirements). that would definitely need to be moved to the GNOME infrastructure, if it was meant to be included in the desktop modules. if we're just talking about the engine then I don't see the point of having the discussion in the first place, until something explicitly requires the engine; and in that case, the engine should go through the external dependencies list - in which case there wouldn't be the issue of where it is hosted/developed. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
2010/4/22 Frederic Peters fpet...@gnome.org: We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release., but release team is too late for translators. Yeah, I agree that copying stuff over just before we release isn't really useful. Here is what I envision: - Translations handled using GNOME infrastructure, that's fine. - For the code, trunk could be moved to Git with Launchpad mirroring it. Most of the actual development would probably still happen in branches, but periodically landed into trunk. Rodrigo said that's what he does too so I don't see how it's a problem. (By the way, Seif and Markus will need Git accounts if that's what we do). - Switching to another interface for bug/blueprints/reviews part is the biggest issue (it's not about the data, but the fact that Launchpad is what works best for us). Personally I'd be happy with a middle-ground like having Launchpad as the main tracker, but accepting bug reports on Bugzilla and forwarding those to Launchpad. Cheers, -- Siegfried-Angel Gevatter Pujals (RainCT) Free Software Developer 363DEAE3 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
