Re: How do you hack on the bleeding edge of Gnome?
On 04/19/2012 02:43 AM, Sriram Ramkrishna wrote: There should be a continuous build going on, and when it fails the module owner should be informed that their module has failed and it should be fixed, IMHO. I think a lot of people would thank us. There is, sorta: http://build.gnome.org/gnome-keyring The problem is you have to subscribe, and that via feeds, and I often miss the notifications in my mail client. Would be far more helpful (to me at least) if it spammed xxx.doap maintainers when the build fails. Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on the bleeding edge of Gnome?
On 04/19/2012 12:55 AM, Federico Mena Quintero wrote: So this mail is about: how do *you* hack on Gnome on an everyday basis? jhbuild. Which often makes me sad. It's gotten better, but I find that I'm constantly fixing build problems, and/or waiting for the stack to compile. It's gotten to the point where I often start a build every few days, whether I need it or not, fixing build problems along the way, so that when I actually need to hack on something it's ready. Do people get their source trees built only up to the modules they hack on, and ignore the rest (been there, done that)? Yup :S Do people wait until a distro carries packages for development versions (too late in the game; been there, done that)? In the modules I've maintained I'd had tried to only depend on stuff released in the latest distros. But more recently I haven't been able to do that anymore due to 1) me splitting related stuff up into multiple modules, and 2) the feature-based development style of GNOME. How would *you* make Gnome score higher on the Joel Test? Probably by having a continuous build which produces installable development packages based on Alex's Glick 'bundles': http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/ Cheers, Stef ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on the bleeding edge of Gnome?
On Wed, 2012-04-18 at 17:43 -0700, Sriram Ramkrishna wrote: On Wed, Apr 18, 2012 at 4:45 PM, Colin The issue is not so much time as unreliability. I've tried to address some of those with jhbuild, but there are two major ones remaining: 1) Building from unclean source tree - stale Makefiles, leftover binaries, etc. 2) Our lack of multi-module continuous integration There should be a continuous build going on, and when it fails the module owner should be informed that their module has failed and it should be fixed, IMHO. You mean http://build.gnome.org/ and its per-module RSS feeds? Philip I think a lot of people would thank us. ___ 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: How do you hack on the bleeding edge of Gnome?
Hi Federico! On Wed, 2012-04-18 at 17:55 -0500, Federico Mena Quintero wrote: I've been having a terrible time trying to get something tested on top of Gnome 3.4, all because I can't get 3.4 built from jhbuild. I'm too old to build from tarballs, and my distro doesn't carry 3.4 yet. I wonder how people who hack on core Gnome do it on a day to day basis. Here are the results of a little poll/brainstorm on Twitter: https://live.gnome.org/BuildMeHarder As a quick summary, the problems we have with jhbuild are: 1. Build everything before you can contribute is a *HUGE* brick wall for contributors both regular and sporadic. 2. Jhbuild is unreliable for obscure reasons. People don't have the time or skills to fix every little autotools problem that comes up - these seem to happen all the time (what do you mean libtool macros not found!? I already built 20 modules that use libtool!). GISCAN fails regularly with unknown symbols. Etcetera. 3. Packages fail to build due to missing external dependencies, but you don't get notifid until the package fails to build. It's not nice to get a failure in NetworkManager, after half a day of building, just because I didn't have the distro's ppp-devel package installed. It would be nicer to get notified in advance. a solution for this would be to have a jhbuild package for your distro, with all the dependencies, although that might be overkill, as it would depend on lots of libraries, that maybe you don't need if you don't build everything 4. You ask on IRC, and more often than not the best answer is, wipe everything and try again. I never do this! I prefer to have an old module around than being unable to build everything because a base module doesn't build :-) 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: How do you hack on the bleeding edge of Gnome?
Hello Federico, On 18/04/12 23:55, Federico Mena Quintero wrote: I've been having a terrible time trying to get something tested on top of Gnome 3.4, all because I can't get 3.4 built from jhbuild. I'm too old to build from tarballs, and my distro doesn't carry 3.4 yet. Disclaimer: I've not build 3.4 either. I wonder how people who hack on core Gnome do it on a day to day basis. I think core developers are likely to have less problems generally because their dependencies are lesser. For Tracker, I've experienced many issues over the years trying to get Tracker to build with jhbuild and not from its direct dependencies but random crap in the moduleset that is available with the deps I need. Here are the results of a little poll/brainstorm on Twitter: https://live.gnome.org/BuildMeHarder Great list there, I completely concur on all accounts. As a quick summary, the problems we have with jhbuild are: 1. Build everything before you can contribute is a *HUGE* brick wall for contributors both regular and sporadic. 2. Jhbuild is unreliable for obscure reasons. People don't have the time or skills to fix every little autotools problem that comes up - these seem to happen all the time (what do you mean libtool macros not found!? I already built 20 modules that use libtool!). GISCAN fails regularly with unknown symbols. Etcetera. 3. Packages fail to build due to missing external dependencies, but you don't get notifid until the package fails to build. It's not nice to get a failure in NetworkManager, after half a day of building, just because I didn't have the distro's ppp-devel package installed. It would be nicer to get notified in advance. This one really irritates me. 4. You ask on IRC, and more often than not the best answer is, wipe everything and try again. I don't want to blame jhbuild; this is a larger problem with how we have structured the development of Gnome. I'm happy that (e.g.) Colin Walters is working on ostree ( http://git.gnome.org/browse/ostree/tree/README.md ), but while it seems like a truly fantastic way to install prebuilt binaries without disrupting your system, it doesn't solve the problem of building those binaries in the first place - correct me if I'm wrong! So this mail is about: how do *you* hack on Gnome on an everyday basis? I don't use jhbuild unless I need a *serious* number of dependencies to build my projects. For example, if the Evolution miner in Tracker fails because of new API requirements in the Evolution development libraries. This is horrific. It take a *lot* of energy to get a full build working. When talking about it internally at Lanedo in the past, I would often hear the guys say they create their own modulesets because the standard ones are too big and never fully build either. I have ended up hacking moduleset deps to avoid building stuff I don't want to build (if I can) OR completely ignoring errors for some libraries and only coming back to those where that vetoes the project I need to use in my project. Do people get their source trees built only up to the modules they hack on, and ignore the rest (been there, done that)? I try not to, but more and more I do these days because of the energy required to get a full build working. You might think it's not much energy, but I have yet to build a FULL moduleset without issue since I started using jhbuild. Most of the time, this is dependency or system autotools issues. Less occasionally it's some build issue for a particular project. Do people wait until a distro carries packages for development versions (too late in the game; been there, done that)? How would *you* make Gnome score higher on the Joel Test? With Tracker, we try to keep dependency version requirements down to what the next big distros are shipping, so if I am using Ubuntu Oneiric and we have a patch to fix our libgrss use to the new 0.5 API, we will check what Natty and F17 are shipping to avoid pain for other developers wanting to build Tracker. There are cases where you can't do this (e.g. requiring the latest Vala that's not been released because of some crash). But we (as a project) try to make things easier. We certainly don't depend on new libraries because they exist. We only depend on libraries if we need that version for some API requirement. (Side thoughts: how many people have *actually* tested a full 3.4 install?) Not me. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on the bleeding edge of Gnome?
On Thu, Apr 19, 2012 at 00:55, Federico Mena Quintero feder...@gnome.org wrote: I wonder how people who hack on core Gnome do it on a day to day basis. I used jhbuild every day for a few years when I used to hack on Sugar and at some point I stopped using jhbuild commands other than 'shell', resorting to pulling and building each repo by hand. This was because of the pain of automatic dependency handling. These days I mostly hack just on clutter, pygobject and g-i (and not that often any more), so I have cooked my own script that does only what I used jhbuild for (see attachment). I would recommend this to application authors that don't need more than 3 or 4 libraries in their unstable branches. For hacking on the Shell, I guess something as full-blown as jhbuild is needed. My most vivid memory of jhbuild is having to help newcomers to build Sugar in their favourite distro, it was a nightmare. Regards, Tomeu bp Description: Binary data ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature Proposal: finding and rediscovering shared links
Ben, Peter, and Bruce share links to interesting articles and videos and sometimes they can't check it, like if Bruce is in a meeting or out and about on his phone, but if his computer also kept track of the link in IM, then he could look at it then. So one thing is that Bruce is unavailable to look/read/watch something, so defering it to later is an option. Another is if Bruce is looking at something and needs to come back to it. E.g: Someone sent Bruce a link to bugzilla and Bruce remembers that he wants to check on it and do stuff w/ the bug, but 2 or 3 days later or the next week he asks himself where where was that bug again?. Seperating those links into links one has NOT been to yet, but are in messages, are even more interesting. It would be nice to see a recently encountered link view, where the user can see can see a list of links shared with the him. E.g: Sometimes Ben asks Bruce about some link he shared with him. It would be nice if Ben could just find it based on the content of the link and links they shared (sometimes he's not sure it's Bruce, but it's most likely Bruce) Bruce could use that same tool to look at links he shared with Ben: What was that page of that JavaScript library that does the animation thing that you sent me a few months ago? That happens a good bit, not all the time, but often enough, since both often share things with each other but one or the other of them forgets. Some of the stuff they share is just for fun other things are useful for work. And it's all mixed in together. Often, the funny and interesting things are videos and then the work stuff has various keywords, like css or javascript or such (and are usually not videos) So a possible view for this feature can be done in Web: Links received can then be automatically put in the queue of Web. And once visited can be taken out of the queue. Another possible view would be a dialog for sent/received links for the Contacts application. To sum it up: it would be appealing to have a readitlater queue without explicit managing (well allowing that, and having those prioritized) as well as having links sent through some direct mean (IM, mail) populate it. One might argue that sharing happens via Social networks but a lot of it happens via IM and E-mails too. The concept applied for both. I have 2 mockups for this idea... The first would blend in nicely with the current designs of Web http://i.minus.com/ibfFpg4wMTscf0.png The second would require adding a new view but has the advantage of allowing a more interactive as well as informative (contextual) display of the links http://i.minus.com/ibq81FRZb2iII4.png Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
On 19/04/12 15:40, Seif Lotfy wrote: Ben, Peter, and Bruce share links to interesting articles and videos and sometimes they can't check it, like if Bruce is in a meeting or out and about on his phone, but if his computer also kept track of the link in IM, then he could look at it then. Interesting idea. Back when I was working on Gossip, I had a links tab in the chat log/history for exactly this reason. I frequently dig out old links. The most important things are: - The link - Who sent it - What medium - When That's at least how I generally try to find links I've been sent. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on the bleeding edge of Gnome?
On Wed, 2012-04-18 at 17:55 -0500, Federico Mena Quintero wrote: I've been having a terrible time trying to get something tested on top of Gnome 3.4, all because I can't get 3.4 built from jhbuild. I'm too old to build from tarballs, and my distro doesn't carry 3.4 yet. I wonder how people who hack on core Gnome do it on a day to day basis. Here are the results of a little poll/brainstorm on Twitter: https://live.gnome.org/BuildMeHarder snip So this mail is about: how do *you* hack on Gnome on an everyday basis? Do people get their source trees built only up to the modules they hack on, and ignore the rest (been there, done that)? Do people wait until a distro carries packages for development versions (too late in the game; been there, done that)? How would *you* make Gnome score higher on the Joel Test? I build the minimum stack that isn't shipped by my distribution. That means that I use released development versions of almost everything but the component I'm working on. This also means I can compare my experience with other people running the packages, rather than compare versions of every component in the whole stack. (Side thoughts: how many people have *actually* tested a full 3.4 install?) I did, mostly through my distribution. Building the whole desktop and dependencies to test one program would drive me up the wall. ___ 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: How do you hack on the bleeding edge of Gnome?
On Wed, 2012-04-18 at 17:43 -0700, Sriram Ramkrishna wrote: On Wed, Apr 18, 2012 at 4:45 PM, Colin The issue is not so much time as unreliability. I've tried to address some of those with jhbuild, but there are two major ones remaining: 1) Building from unclean source tree - stale Makefiles, leftover binaries, etc. 2) Our lack of multi-module continuous integration There should be a continuous build going on, and when it fails the module owner should be informed that their module has failed and it should be fixed, IMHO. I think a lot of people would thank us. Honestly, I think if we just: * added a couple more buildbots to http://build.gnome.org/ * ensured buildbot uptime and operation * ensured they all mailed maintainers upon build failures we would be in much better shape. Though there are some unique problems with jhbuild that can make this hard to get right (which is why I suspect we don't already notify about build errors). Some of these (off the top of my head) are: * build system errors * maintainer error (invalid build config) * autotools/macro annoyances (eg, failure to pull in libtool macros) * wedged build state 'make *clean' won't fix (must git clean -xdf) * older installed library versions cause linking errors * this happened with GLib in recent memory (this cycle or last) * older version must be uninstalled to resolve * if the build bot builds from scratch regularly, they won't hit this error that developers easily can * soft ABI breaks (eg, g-i or Vala) which can require a combination of re-building and even first uninstalling several intermediate modules * this gave Folks a lot of trouble, especially in the beginning * g-i and Vala have mostly settled these issues, but I would hate to have another up-and-coming dependency run us through the same issues I'm sure there are some I'm forgetting. But the reason these would be hard to solve is that they mostly can't be fixed by the maintainers after-the-fact. There's no way to propagate a jhbuild uninstall module; jhbuild buildone module to jhbuild users (though I honestly wonder if the issues that this would fix can't be solved in a more natural way). I think if we wanted rock-solid buildability, we would need two-stage mainlining (where Gnome mainline repos would only pull the latest maintainer mainline commits if they built successfully on the buildbots). I can imagine avalanche of reasons why this would be infeasible for our development model. But I think until we can resolve problems like the one ones above (and throughout this thread), building most modules and their dependencies through jhbuild will remain an exercise in frustration, limiting it to very dedicated contributors. -Travis smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on the bleeding edge of Gnome?
Hi Federico, On Wed, 2012-04-18 at 17:55 -0500, Federico Mena Quintero wrote: I've been having a terrible time trying to get something tested on top of Gnome 3.4, all because I can't get 3.4 built from jhbuild. I'm too old to build from tarballs, and my distro doesn't carry 3.4 yet. I wonder how people who hack on core Gnome do it on a day to day basis. I use jhbuild and to be honest I cannot remember last time I had a blocking problem with it... in fact I just run a build from scratch last week and it did not stop once. Worse problem I can remember in the last couple of years or so is that the URL for one of the external dep tarball was currently offline. I think the trick is to have a well trusted jhbuildrc[1] which skips stuff like dbus or NetworkManager and to make sure to have all the required development tools and low level libraries installed from your distro. For instance this[2] is the collection of packages I install. I admit however I do not usually build some of the difficult modules like gdm etc. That said, I cannot recall how many times I helped people on irc to get started with jhbuild and I really look forward to a better tool that lowers the barrier of entry to get started hacking on gnome. walters' ostree definitely looks promising. (Side thoughts: how many people have *actually* tested a full 3.4 install?) This is a very valid concern that has been bugging me for a long time: a few years ago I used to run a full jhbuild session as my day to day environment and I was not alone doing it, but when distros started to pick up the 6 months cadence, it simply became easier to run a development distro. That however has many effects: first of all I upgrade to the beta version of my distro usually late in the cycle. Beside, when running binary packages, if I stumble in a small bug in a random module, sometimes I do not have the energy to go checkout the sources, reproduce, debug etc etc. Relying on downstream distribution for testing also has the problem that when ubuntu decides to skip a cycle our QA level drops noticeably. Once again it looks like our best bet is to wait for walters to give the green light on ostree. Paolo 1: http://people.gnome.org/~pborelli/jhbuildrc 2: http://people.gnome.org/~pborelli/postinstall.sh.txt Federico ___ 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
