Re: Underlying DE for the Fedora Workstation product
On Wed, 2014-02-05 at 16:00 -0500, Mike wrote: [...] I don't know how does the testing goes inside RedHat, but I found GNOME 3 still needs to be tested far more than now before each release. Example above indicates that the testing process does not even consider about existence of input context at all. Wait a minute. GNOME is developed by a bunch of people, volunteers and from different affiliations. Some of them are Red Hat employees to work full time on GNOME, everybody appreciate that. But that is not a reason to dismiss the effort of many volunteers who work on GNOME in their spare time. It is known in GNOME that we lack of testers, people who take the time to build and test the whole desktop *before* it is released. That was also true in the GNOME 2 era. Something that should start changing with gnome-ostree (you should take a look at that!). You would be very welcome to test GNOME and file descriptive bugs that allow to improve the quality of a GNOME release. BTW, may be a little off topic. I'm confused a bit about the target or the goal of GNOME 3 right now. Just this morning I was told on the bugzilla that GNOME maintainers are not meant to be the slaves of popularity contests. Does this imply that GNOME 3 will not target for number-one free software OS? There are a lot of feature requests in the mailing list and bugzilla by the users, and maintainers decided to drop them for simplicity. It seems to me that maintainers of various components do not want it to be popular, or at least do not want to be popular among those users who requested those features. (I'm not being hostile at this idea at all, it's completely understandable and for sure a lot of ugliness are introduced by feature requests by massive users.) If one million of flies like sh*t, it does not mean that the sh*t is good. Try to walk on maintainer/volunteer shoes. Let's assume I am maintainer: In my not copious spare time, I work on the features I would like to use myself. I will be happy hacking on them and I will be happy using them once they are done. If those are good for you, great. If those makes my application popular, great. If not, move on. I prefer to work on something I enjoy, rather than allowing other people to set my priorities and make unhappy in my spare time. However, I am open to discuss fair points that make me change my priorities, but that should not take more time than I would use for hacking. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do I pursue a gnome-shell memory leak ?
On Thu, 2013-12-05 at 14:32 +0200, Petko Ditchev wrote: I see that the process starts eating memory in no particular way . Sometimes it stays at ~120MB , and some times it starts rising and can reach 1.5GB . I alt+F2 : 'r' , to restart the shell and put out the fire , but the issue has to get fixed at some point , and I don't know what additional info I can give in a bug report . I'm on Manjaro , updated (gnome-shell 3.10.2.1-1) . Maybe related to https://bugzilla.gnome.org/show_bug.cgi?id=685513 -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updates from the GNOME Sysadmin Team
On Thu, 2013-11-21 at 22:23 +0100, Andrea Veri wrote: 2013/11/21 Ekaterina Gerasimova kittykat3...@gmail.com [...] When you document how to lock down individual pages to prevent random people from from editing them, please send the link to the mailing lists as it is moderately complicated if one has not done it before. Sure, that can be done this way: 1. Create a page with the following syntax: 'SysadminGroup' 2. add a list of wiki usernames like https://wiki.gnome.org/SysadminGroup 3. add the ACL at the beginning of the wiki page you want to lock down: #acl WikiPageName/SysadminGroup:read,write,delete,admin,revert All:read Beware that the group wiki page name *must* end in 'Group'. Otherwise, you can get an immutable wiki page that nobody can edit [1] (only a sysadmin, Andrea: it would be great if you could delete it :-). Tip from someone who learned that in the hard way (of course, I followed the standard procedure of reading the documentation [2,3] afterwards :-) [1] https://wiki.gnome.org/Travel/CurrentCommittee [2] http://moinmo.in/HelpOnAccessControlLists [3] http://moinmo.in/HelpOnGroups -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, 2013-08-15 at 18:00 +0200, Christophe Fergeau wrote: 2013/8/15 Debarshi Ray rishi...@lostca.se: If you are using GMail (a proprietary web application) for your GNOME work, and then turn around and start objecting to the use of GitHub as another / secondary distribution channel for our code, then, yes, I do find it insincere. Running your own email infrastructure is much much more easier than replicating GitHub with free software. If you don't even care about the easy things, then who are you to hold others to even higher standards? In my opinion, there's a big difference between someone's personal use of a non-free service, and GNOME as an entity (which is supposed to develop and promote free software) promoting a non-free service. This is what the GNOME's official GitHub mirror tagline makes it sound like. Maybe the wording has not been the best and I agree that the tagline might sound like an endorsement, whereas it should not be. Maybe we would need to make it clear. Nevertheless, I believe there is more than this. In the past, somebody made a mirror of GNOME repositories in GitHub. IIRC, way before Alberto mentioned for the first time some months or years ago. The problems with that mirror were: * It was outdated * There were people forking some of those repositories * It was not controlled by us This problem might happen with any mirror, but GitHub is too popular to ignore it. We might want to have control and let people know about it. If there were more mirrors in GitHub, at least the one called GNOME is from GNOME and it is updated. We could add information to let people know that the one there is only a mirror, the fun stuff is happening in gnome.org and educate them about Free Software. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Travel assistance applications to attend to GUADEC
On Tue, 2013-05-28 at 13:20 +0900, Tristan Van Berkom wrote: On Tue, May 28, 2013 at 8:23 AM, Germán Póo-Caamaño g...@gnome.org wrote: On Mon, 2013-05-27 at 14:47 -0700, Germán Póo-Caamaño wrote: The GNOME Foundation provides travel sponsorships to individuals that want to attend GUADEC and need financial assistance. We are happy to announce that the Travel Committee is ready to receive applications for sponsorships to attend to GUADEC 2013. The instructions are detailed at http://live.gnome.org/Travel Please read them carefully. Deadline: May 31, 2013, 19:00 UTC. You can start sending your applications now! After further consideration the new deadline is: June 3, 2013, 19:00 UTC. I'm a little confused, or perhaps just unfamiliar with this process. How can the deadline to request sponsorship be on June 3rd when the deadline for speakers to confirm their attendance is already June 2nd ? Bad combination of factors. However, speakers are encouraged to apply soon. If the only reason that a speaker has to not confirm yet is the sponsorship, then you should confirm and say you are applying for sponsorship. We will coordinate with the papers committee. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Travel assistance applications to attend to GUADEC
The GNOME Foundation provides travel sponsorships to individuals that want to attend GUADEC and need financial assistance. We are happy to announce that the Travel Committee is ready to receive applications for sponsorships to attend to GUADEC 2013. The instructions are detailed at http://live.gnome.org/Travel Please read them carefully. Deadline: May 31, 2013, 19:00 UTC. You can start sending your applications now! Some additional comments: * Any information you send to the Travel Committee will be private. * Asking for sponsorship *does not* guarantee you will get sponsored. * A good application with good information will be processed faster. * If you need help with accommodation, the Travel Committee will book the hotel or hostel for you. This enables us to get group rates and provide accommodation assistance to as many people as possible. You should state that you need accommodation, and leave the cost blank. * Always choose the most economical option whenever possible. People who need travel sponsorship, should look for the best price (i.e. through a service like kayak.com). If the Travel Committee finds a cheaper price, that will be the price considered during the evaluation. * There are direct flights to Brno available through budget airlines. These are considerably cheaper and take 30 minutes to get to the the city centre instead of a few hours. Other close airports are Prague and Vienna. * If you are in the Google Summer of Code program (as student or mentor) you should mention it in your application. Preference will be given to students and mentors participating in the Google Summer of Code or the Outreach Program for Women. GSoC students usually get a percentage of their GUADEC expenses covered. * If your abstract was accepted to be presented at GUADEC, you should mention it in your application. Preference will be given to people giving presentations at GUADEC. * The Travel committee should confirm that we have received your application within 2-3 days. After that we would accumulate all the sponsorship requests and process them together. So please do not panic (and have any butterflies in your stomach) if we take some time to respond with the status. Regardless of whether your application is accepted or rejected, you will always receive a response. * No personal emails. Please keep travel-committee Cced on all of your replies. You can find us in the #travel channel at irc.gnome.org. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Travel assistance applications to attend to GUADEC
On Mon, 2013-05-27 at 14:47 -0700, Germán Póo-Caamaño wrote: The GNOME Foundation provides travel sponsorships to individuals that want to attend GUADEC and need financial assistance. We are happy to announce that the Travel Committee is ready to receive applications for sponsorships to attend to GUADEC 2013. The instructions are detailed at http://live.gnome.org/Travel Please read them carefully. Deadline: May 31, 2013, 19:00 UTC. You can start sending your applications now! After further consideration the new deadline is: June 3, 2013, 19:00 UTC. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
On Wed, 2013-04-17 at 13:10 -0400, Jesse Hutton wrote: Lets consider a concrete example. Before Gnome Shell was initially released, I (like many others) didn't like the lack of a power off option in the system menu (or anywhere on the desktop). I've been an on and off lurker on IRC for a while. I brought up the concern a few times perhaps. At one point, I got into a small debate with owen about the design/user experience trade-offs of the issue. He made multiple specific arguments *against* having it in the menu and for having suspend (which I found completely unconvincing). I made multiple arguments *for* including it in the menu. It ended with him saying he'd wasted enough time debating the issue. This example is not an usability study, it was a debate between 2 people having different opinions. I could also make the case in opposite direction, debates that proven to be right with the time, in both 2.x and 3.x cycles. The most famous that comes to my mind is workspaces versus viewports. Today nobody cares. Does this prove anything? I do not think so. Three release cycles later, all of a sudden, there's a power off option in the menu right where suspend used to be (with the inverse behavior now! Alt-click - suspends). I'm glad for it; don't get me wrong. But, what I'd like to know is, what arguments were made to finally convince owen and whoever else pushed through the change? Were the arguments he mead before somehow obsolete? I'd be fascinated to know, since I did my best to make a persuasive case before and was ultimately shot down. (Seriously, if anyone knows of a record of this, I'd like to see it) What makes you think that Owen changed his mind? or what makes you think that he did the changes? or what makes you think the change was done because of your arguments? I do not know, but it could have been all coincidence and -perhaps- the 'I told you so' argument does not apply here. This seems to be the relevant bug: https://bugzilla.gnome.org/show_bug.cgi?id=647441 Is it possible a tool like loomio could help? I don't know much about it in particular, but I think it's clear that the Gnome development process could greatly benefit from more of what it appears to facilitate. IMVHO, other problems seem more important to solve in the short-term, such as: 1. Few people are building and testing the whole system since early stage of development. 2. Plenty of bugs (usability issues included) are reported late in the development cycle (after the beta period). There is ongoing work to improve this situation in the long-term, but having a system for voting does not seem to help in none of these unfortunately. It could help in other areas, though. It is different discussing with empirical data than just discussing different points of view (sometimes with a partial understanding of the goals, implementations details or restrictions). IMVHO, the former helps more. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
On Wed, 2013-04-17 at 14:55 -0400, Jesse Hutton wrote: On Wed, Apr 17, 2013 at 2:41 PM, Germán Póo-Caamaño g...@gnome.org wrote: On Wed, 2013-04-17 at 13:10 -0400, Jesse Hutton wrote: Lets consider a concrete example. Before Gnome Shell was initially released, I (like many others) didn't like the lack of a power off option in the system menu (or anywhere on the desktop). I've been an on and off lurker on IRC for a while. I brought up the concern a few times perhaps. At one point, I got into a small debate with owen about the design/user experience trade-offs of the issue. He made multiple specific arguments *against* having it in the menu and for having suspend (which I found completely unconvincing). I made multiple arguments *for* including it in the menu. It ended with him saying he'd wasted enough time debating the issue. This example is not an usability study, it was a debate between 2 people having different opinions. I could also make the case in opposite direction, debates that proven to be right with the time, in both 2.x and 3.x cycles. The most famous that comes to my mind is workspaces versus viewports. Today nobody cares. How do you know that nobody cares? It might be nice to actually have the arguments for and against a given issue documented and archived. It would at least provide some history and evidence as to why certain decisions were made. Some people may find that interesting and valuable. I am pretty sure the discussion (and all the bike-shedding) are documented and archived in bugzilla and the mailing lists. For instance: https://mail.gnome.org/archives/desktop-devel-list/2002-May/msg00173.html Anyway, I do not want to start repeating the discussion over and over again. See http://ometer.com/free-software-ui.html for a good summary (replace GNOME 2 by GNOME 3 and you are done). -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
On Sun, 2013-04-14 at 20:53 -0400, Hashem Nasarat wrote: [...] Sriram, while I agree many problems would be alleviated with more volunteer time, I've witnessed multiple instances in the past 6 months where decisions were not made democratically, despite a clear lack of consensus. Most recently, there were a great deal of changes to the gnome-shell All Applications view very late in the 3.8 schedule, well after code freeze, and despite visible disagreement. Loomio seems to offer an intuitive way of seeing how controversial a change is. If I’d asked people what they wanted, they would have asked for a better horse -- Henry Ford [1] Software development is not a democracy. Decisions are taken by people who actually develop the software. Comments might or might not be welcomed depending of several factors (politeness, pertinence, reputation, data, etc.). Some decisions have proven better with the time, some others don't and get fixed (or tried a different path). In the development cycle there are plenty of opinions of people (including developers) who have not tried them. Some of them are still valuable, but without real data (not anecdotes) is hard to convince anybody and require to make a good case. At the end of the day, you have to convince people doing the work, who also are actual users of what they develop. [1] Although there does not seem evidence he really said that, you get the point. Another example you can find it http://bergie.iki.fi/blog/no-smartphones/ -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Management Tools used by Gnome project
On Sat, 2013-04-13 at 03:59 +0300, אנטולי קרסנר wrote: Hello everybody, I'm gathering information about how free software projects are managed and I'll be thankful if someone can explain briefly which technologies are used by Gnome. I think that Producing Open Source Software: How to run a successful Free Software project by Karl Fogel is a good starting point. http://producingoss.com/ -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Management Tools used by Gnome project
On Sat, 2013-04-13 at 04:26 +0300, אנטולי קרסנר wrote: On ו', 2013-04-12 at 18:05 -0700, Germán Póo-Caamaño wrote: On Sat, 2013-04-13 at 03:59 +0300, אנטולי קרסנר wrote: Hello everybody, I'm gathering information about how free software projects are managed and I'll be thankful if someone can explain briefly which technologies are used by Gnome. I think that Producing Open Source Software: How to run a successful Free Software project by Karl Fogel is a good starting point. http://producingoss.com/ Thanks, it is very useful indeed. But I'd like to hear some more: How and where is the release cycle managed? How does cross-module communication and management happen? https://live.gnome.org/ReleasePlanning/ -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PyGTK again (was: Apologize and to take PyGTK)
On Thu, 2013-04-04 at 15:52 -0400, Mike wrote: Hi I'm glad to see both side of you calm down . I feel that this could be a typical misunderstanding between users, package maintainers and the upstream developers. Could we do anything about this? I suggest we could setup a activity graph for each modules in the git repository. So people could see how active or inactive is a project before or after they report a bug. This could also be helpful to track inactive/dead projects for release management. Maybe you mean something like blip. http://blip.blip-monitor.com/ (or a specific view of blip). -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build.gnome.org
On Wed, 2013-02-06 at 20:36 -0800, Sriram Ramkrishna wrote: OK, what you're saying is that you get all the modules you want to get except the one module you want to hack on. You get that from git, and then it should work. Strictly speaking you only need the dependencies of the programs you want to hack on. This makes sense because it's not likely going to run into dependency problems like you would if you get all your packages from the master packages. The downside though is that you have to do a configure;make;make install for a lot of packages. Unless there is some hack on jhbuild to build from tarballs? The hack you need is to download the module sets from http://ftp.gnome.org/pub/GNOME/teams/releng/3.7.4/ ;-) You might want read: https://live.gnome.org/Smoketesting And eventually, check: http://git.gnome.org/browse/releng/tree/ and https://live.gnome.org/ReleasePlanning/MakingARelease to get an idea how the release team does it. -- Germán Poo-Caamaño http://calcifer.org/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Blocker bug status
On Sat, 2012-09-15 at 13:03 -0400, Matthias Clasen wrote: Here is another blocker bug review, on the eve of the hard code freeze. There are currently 27 bugs that are marked as 3.6 blockers. There is a bunch of libsecret migration [1] bugs. These are not _really_ blocking 3.6, so I propose that we drop these from the blocker list if they don't get resolved for .92: [...] 679855 evince This one is waiting for feedback from libsecret's maintainer. [...] There is a single bug of the doc infrastructure migration [2] left. While not really blocking 3.6, getting this out of the way would let us drop the old documentation infrastructure modules altogether, which would be a nice achievement: 683354 Port to new documentation infrastructure AFAIK, there is a fair concern on this because of the potential impact on translations: shaunm I'm tempted to just say push it, and if there's anything wrong I'll catch it making a release shaunm but I'm a little concerned about needlessly breaking translations this late shaunm because itstool and xml2po can produce different messages in some cases shaunm can we check that easily? -- Germán Póo-Caamaño http://people.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting GNOME Games and modules names (gnome-chess etc)
On Fri, 2012-08-31 at 21:02 +1200, Robert Ancell wrote: Hi, For 2.8 we are now in a state to split GNOME Games into separate modules. Here are the current binary names of the games and the proposed module names for them: [...] 3. Any advice on how to transfer the code to the new modules? Do we lose all the git history? No, you should not lose the history. git filter-branch is your friend. Check: http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository -- Germán Póo-Caamaño http://people.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Again: please clarify the decision on IBus integration
On Mon, 2012-07-09 at 13:06 +0800, Aron Xu wrote: On Mon, Jul 9, 2012 at 1:02 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Sun, Jul 8, 2012 at 10:45 PM, Aron Xu aro...@gnome.org wrote: I would like to get your clarification about what's your decision on IBus integration because all of us haven't reached to an agreement on the whole thing. While I feel that you'll do it regardless of complaints from users when reading the Wiki page, which explicitly emphasis the opinions from foreign developers who doesn't use input method at all. This can be frustrating and I'd like to eliminate it, so if I get no certain response in a reasonable time frame, I'll assume that no one is able to speak up about the decision and it's automatically become a not-for-3.6 thing, then I'll revert any commit causing input method related behavior change that are not agreed here. Aron, threatening to 'revert any commit' in modules that you don't maintain is not a great way to reach agreement. I can't give you the 'official' decision that you want, but I am still very much planning to go ahead with the IBus integration for 3.6. The work is being done carefully. Rui has accumulated quite a few patches, and we are waiting for some fixes on the IBus side before landing them. As for complaints, I expect that we will get some feedback when the integration has actually landed...when people have a chance to try it out. I hope you will, too. When you do, keep in mind that this work is still very new and may need a while to mature and reach its full potential. OK, I get the point: users' opinion worth nothing when design said something is good, even there are significant disagreements flow into mailing list, even when you don't use it anyhow. It's completely frustrating and I won't revert anything as you said it was threatening. Did you bring any concern during GNOME.Asia? There were designers attending there. That seemed to be a good opportunity to talk face to face, show in practice the issues, etc. In order to keep the discussion healthy, it is important to keep in mind people mean well for discussion as our Code of Conduct says (https://live.gnome.org/CodeOfConduct) -- Germán Póo-Caamaño http://people.gnome.org/~gpoo/ signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fwd: Questions for the board election candidates
On Tue, 2012-05-22 at 14:07 -0300, gnomeu...@gmail.com wrote: 2012/5/22 Robert Nordan r...@robpvn.net: Hi all, I have a few questions for the candidates in the upcoming election to the board. They are obviously shaped by my interests, but I believe that other Foundation members may be interested in the answers as well. 1) Open Source or Free Software? This is about personal philosophy: Do you prefer the pragmatism of the Open Source Initiative or the political idealism of the Free Software Foundation? (Some of the candidates have already flagged a stance on this.) [...] Why are you using desktop-devel-list y no foundation-list for replying question related to GNOME Foundation candidacies? -- Germán Póo-Caamaño http://people.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: Some points about IM integration
On Tue, 2012-05-15 at 12:21 +0800, Weng Xuetian wrote: I don't want people to draw the conclusion that because I'm saying that input methods should have simple configuration without a lot of options, I think that they aren't important. I'm very aware that every single user that comes to GNOME and wants to write in Chinese needs to use an input method. But if we have so many options that the defaults don't get well tested, or if options conflict and produce bugs, then we're not shipping a good ';';''' ' Options are really required in order to meet people need especially for input method. This is a basic components for people. Is it possible you can enumerate all those special needs and why are compulsory? Just stating the options are important does not help to understand why, neither gives the opportunity to think or determine which approach would fit better. -- Germán Póo-Caamaño http://people.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
Travel assistance applications to attend to GUADEC
Dear hackers, As you may know, the GNOME Foundation provides travel sponsorships to individuals who want to attend GUADEC and need financial assistance. We are happy to announce the Travel Committee is ready to receive applications for sponsorships to attend to GUADEC 2012. This year, GUADEC is being held in the Faculty of Computer Science at the University of A Coruña, in the beautiful city of A Coruña (Spain), from Thursday 26th July until Wednesday 1st August. The instructions are detailed at http://live.gnome.org/Travel Please read them carefully. Deadline: May 16, 2012, 23:59 UTC. You can start sending your applications now! Some additional comments: * Any information you send to the Travel Committee will be private. * Asking for sponsorship *does not* guarantee you will get sponsored. * A good application with good information will be processed faster. * If you need help with accommodation, the Travel Committee will handle it directly with the organization. You should state that you need accommodation, and leave the cost blank. * Always choose the most economical option whenever possible. People who need travel sponsorship, should look for the best price (e.g. through a service like kayak.com). If the Travel Committee finds a cheaper price, that will be the price considered during the evaluation. * If you are applying to a Google Summer of Code program (as student or mentor) you should mention it in your application. * GSoC students usually get a percentage of their GUADEC expenses covered. * If you submitted an abstract to be presented at GUADEC, you should mention it in your application. Preference will be given to people giving presentations at GUADEC. * The travel committee will cross check with the GUADEC paper committee the talks that have been accepted, so as long as you let us know you submitted one, there is no need to follow up. * The Travel committee should reply back about receiving your application within 2-3 days. After that we would accumulate all the sponsorship requests and process them together. So please do not panic if we take some time to reply on the status. Affirmative/Negative you would surely get a response. * If you need an invitation letter, you must clearly state your contributions and name at least two fellow hackers that can directly support your requirement. * No personal emails. Please keep travel-committee Cc'ed on all your replies. You can find us in the #travel channel at irc.gnome.org. Kind regards, -- Germán Póo-Caamaño http://people.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: 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. [...] 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? 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? IMVHO, the trick is to avoid to build the whole pre-defined module sets. Those are too big these days and probably you will not depend on all of them. This means using skip.extend extensively in your .jhbuildrc[1] or create(customize) your own module set file. [1] http://www.vuntz.net/journal/post/2010/09/23/My-love-for-jhbuild If you want to try Gnome Shell, then follow the instructions in http://live.gnome.org/GnomeShell#Building. There is a script pointed there to check the system packages you will need, if jhbuild sysdeps/sanitycheck is not enough. Because of time restrictions, I usually try just specific applications and I use a different module set or jhbuildrc for each one. For instance, I do not try to build programs that touch the system (NetworkManager) or I am not interested (Mozilla) or breaks the build system regularly (I think everybody has a pet here :-). -- Germán Póo-Caamaño http://people.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: Toolbar text size in both mode.
On Sun, 2012-04-01 at 14:39 +0400, Denis Cheremisov wrote: [...] But, nevermind, I'm not the first and the last who was screwed up by gnome shell and these poorly minded decisions :) You will not attract any honey with vinegar. -- Germán Póo-Caamaño http://people.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: About the name of GNOME 3 core application names / translation
On Mon, 2012-03-12 at 08:53 +0200, Luc Pionchon wrote: [...] - copyright notices and such, should the name be so generic? And in translations, should the name be really translated here? Shouldn't it be made more explicit for example with adding GNOME, like in Copyright 2012 - the GNOME app name Developers? IMVHO, any of them is a very bad idea. If there is a copyright violation there would not be any 'real' copyright holder that could complain or sue. Time would be wasted on proving who are the copyright holders. IANAL. -- Germán Póo-Caamaño http://people.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: About the name of GNOME 3 core application names / translation
On Mon, 2012-03-12 at 09:32 +0100, Olav Vitters wrote: On Mon, Mar 12, 2012 at 12:20:32AM -0700, Germán Póo-Caamaño wrote: On Mon, 2012-03-12 at 08:53 +0200, Luc Pionchon wrote: [...] - copyright notices and such, should the name be so generic? And in translations, should the name be really translated here? Shouldn't it be made more explicit for example with adding GNOME, like in Copyright 2012 - the GNOME app name Developers? IMVHO, any of them is a very bad idea. If there is a copyright violation there would not be any 'real' copyright holder that could complain or sue. Time would be wasted on proving who are the copyright holders. Trademark issue, not copyright. And you should not be able to trademark such generic names. With the exception if you are a big company it seems :P I meant GPL violations, which is copyright. -- Germán Póo-Caamaño http://people.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: Prevent screen from going to sleep
On Thu, 2012-03-01 at 10:16 +, Ross Burton wrote: On 1 March 2012 10:07, Marco net...@lavabit.com wrote: I sometimes have a PDF that I want to display without the screen being turned off. That would be View-Presentation in Evince, I believe. For the case of a PDF, it might be. Unfortunately, I have found myself in the same situation often while discussing and/or analyzing different sources of data (charts, tabular data, network graphs, etc.). Usually this has been projecting the media on top of a whiteboard and discussing close to the whiteboard (sort of the SmartBoard of a poor man). The only solution I can find is an extension, as it was the applet. Still the issue does not bother me that much. -- Germán Póo-Caamaño http://people.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: Splitting gnome-utils for 3.4
On Wed, 2011-09-28 at 17:08 +0100, Emmanuele Bassi wrote: hi Olav; I just checked, and the tags and branches haven't been imported in the split repositories. those are the usual suspects for repos being overblown. Tags in git need minimal space (which was different with subversion), and those could be useful in the future (ie. if you need to contact authors from x.y version to now). -- Germán Póo-Caamaño http://people.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: Splitting gnome-utils for 3.4
On Wed, 2011-09-28 at 18:06 +0100, Emmanuele Bassi wrote: hi; no: tags and branches in git reference objects and that will balloon the size of the repository. just look at the gdk-pixbuf repo for an example. I think the problem are not the tags or branches per se, there are repositories with too many unrelated tags/branches. gdk-pixbuf$ git tag | wc -l 354 247 of them are some sort of GTK (multihead support, gtk releases, etc.), from the remaining ones there is even an EAZEL-NAUTILUS-MS-AUG07. So, that is inheritance of the migration that -probably- could be cleaned up. But, the bare repository size of gdk-pixbuf still is 144MB. gnome-utils is 47MB (with 286 tags and 56 branches). Even in the worst case, like evolution with 2248 tags and 494 branches, the bare repository size is 363MB. The bare repository of the whole git.gnome.org (640 repositories) is 9.4G, still 3 times smaller than our previous subversion (which has less history and repositories). My point is to set a middle ground, where it were possible to keep the relevant history (dropping the non-related tags and branches) rather than dropping all tags and branches. Regards, -- Germán Póo-Caamaño http://people.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: GNOME 3.1.90 beta released!
On Fri, 2011-09-02 at 00:18 +0530, Nirbheek Chauhan wrote: On Thu, Sep 1, 2011 at 10:55 PM, Evandro Giovanini efgiovan...@gmail.com wrote: On Thu, Sep 1, 2011 at 12:24 PM, Bastien Nocera had...@hadess.net wrote: See https://bugzilla.gnome.org/show_bug.cgi?id=657496 I hope we get some hardware that's a bit more advanced than this 1990's behaviour in the future. As someone misfortunate enough to have used a WM phone for a few months I don't see what's so bad about the classic behaviour (for the lucky ones that may be unaware, I basically had to manually remove the battery every other week to recover from an OS crash). On my laptop, I encounter enough hard lockups while testing software that the long-press behaviour of the power button is essential for me. I don't want to have to flip my machine over and take out the battery everytime. For all I know, doing that repeatedly might even damage the device. In the worst case, you still can use the Magic SysRq key. http://en.wikipedia.org/wiki/Magic_SysRq_key -- Germán Póo-Caamaño http://people.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: GNOME user survey 2011
On Mon, 2011-08-01 at 11:00 +0300, Felipe Contreras wrote: On Mon, Aug 1, 2011 at 12:49 AM, Olav Vitters o...@vitters.nl wrote: On Mon, Aug 01, 2011 at 12:16:54AM +0300, Felipe Contreras wrote: On Sun, Jul 31, 2011 at 11:14 PM, Olav Vitters o...@vitters.nl wrote: On Sun, Jul 31, 2011 at 07:11:34PM +0300, Felipe Contreras wrote: [...] === 03. How do you describe the amount of configurations available? === I don't see the relevance of asking this. Furthermore the question is suggestive. Seems more to prove a point than anything else. I do see the relevance, as I think it has been a big point of contention raised by many users. Something should be done with a survey. No matter the outcome of this question, you won't be able to take these results and change things. Asking if people want more configuration options goes against why options are removed. Ideally everything should happen automatically. I'm only interested in the cases where it doesn't work. I other words, you are saying that it doesn't matter if 100% of the responders of this survey say GNOME has too few options, nothing would be done? Is there *any* kind of evidence that would convince GNOME ppl that users want more options? Or is it what the wishes of users are completely irrelevant? First at all, you need to define a goal, what are you going to do with the results and what kind of actions would be needed to improve the results in a future survey. That said, if you get: 40% users answered 'Too many options' 10% users answered 'just enough' 50% users answered 'few options' Then, so what? There is no useful information you can get from this. What do we need to improve? Add more options. (!?) Having configuration options is an implementation detail. Olav points it out correctly, and his suggestions goes in the right directions: does GNOME do what you want? with a text field to specify what it lacks. The results should be far more concrete than asking whether they like it or not. So, how can you formulate better questions for a survey? Taking a text book of HCI. For instance: http://hcibib.org/tcuid/index.html In particular the chapters 4 and 5 (Evaluating the Design with and without users). The type of questions is more or less similar. Another text book could be http://goo.gl/wkBje (not available online, though). Part 4 (chapter 20 to 27). Later, you might want to run an Heuristic analysis in order to get more concrete and objetive points, set goals, etc. Having several evaluators will help you to get the common findings and discuss the differences, which would lead the set the proper questions for a survey or user study. Regards, -- Germán Póo-Caamaño http://people.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: GNOME user survey 2011
On Mon, 2011-08-01 at 12:21 +0300, Felipe Contreras wrote: On Mon, Aug 1, 2011 at 12:00 PM, Germán Póo-Caamaño g...@gnome.org wrote: [...] That said, if you get: 40% users answered 'Too many options' 10% users answered 'just enough' 50% users answered 'few options' But what if you get: 2% users answered 'Too many options' 10% users answered 'just enough' 88% users answered 'few options' So what? -- Germán Póo-Caamaño http://people.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: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)
On Mon, Mar 21, 2011 at 09:21, Alberto Ruiz ar...@gnome.org wrote: Hello Olav, What is the reasoning behind this move? Just storage savings? It seems to me that it will actually be easier to request our sponsors (RedHat/Novell/Oracle...) for more storage than pushing everyone into the pain of having to deal with such unfamiliar format. We are releasing .gz and .bz2 at the same time at the moment. Getting rid of .gz would be reasonable, bz2 is supported everywhere for many years, whereas .xz, well, is the first time I hear about it. We cannot assume that the change won't have an impact just because most modern Linux distros have packages to support the format. I am not trying to criticise the effort rather than trying to understand why is this such a big win. The explanation is in the following previous thread: https://mail.gnome.org/archives/desktop-devel-list/2011-March/msg2.html The problem is not storage, it is bandwidth. -- Germán Póo-Caamaño http://people.gnome.org/~gpoo/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git: Do not use http to access Git!
On Fri, 2011-02-18 at 05:46 +, Tshepang Lekhonkhobe wrote: On Thu, Feb 17, 2011 at 09:48, Olav Vitters o...@vitters.nl wrote: Please note that to checkout a Git repository you should use: git clone git://git.gnome.org/[project] or (if you have commit access): git clone ssh://[login@]git.gnome.org/git/[project] Do NOT try to checkout via http. It is not something we support! Some people have been using the cgit interface to checkout a lot of git modules. This cause a very high load on our server. Please use the git protocol instead. For now I've blocked git from accessing cgit as too many people have been using the http interface and it negatively impacts performance (very high loads over long periods). Do you mind explaining what's causing bad performance when using http... why is it less efficient than using git protocol? This is documented in: http://progit.org/2010/03/04/smart-http.html http://progit.org/book/ch4-1.html http://progit.org/book/ch9-6.html -- Germán Póo-Caamaño 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: IRC channels in gnome development
On Mon, 2011-02-07 at 14:53 -0800, C.J. Adams-Collier wrote: Yeah, we don't have that sort of service. If you'd like, I can talk with the rest of the crew about putting something together. Slightly related, HipChat got IRC a step ahead (less geeky, more pleasant and with log recording). I mean, the concept not the product. http://www.hipchat.com/ (Just in case there is somebody interested in working in something like this :-) On Mon, 2011-02-07 at 19:52 +0100, Andre Klapper wrote: On Sun, 2011-02-06 at 19:19 +0530, Nirbheek Chauhan wrote: Is there a place where IRC logs of discussions from the various channels can be found? I am not aware of any automated GimpNet IRC channel logging and publishing. andre -- Germán Póo-Caamaño 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: IRC channels in gnome development
On Sat, 2011-02-05 at 11:43 -0600, Paul Cutler wrote: You're asking to change the way things have been done for years - which isn't an argument to not do things that way, but just pointing it ou. However, the GNOME Design team has regular office hours in IRC where everyone is welcome to come and ask questions - I'm not a designer, but I don't know what more you can ask for if IRC is going to be used. Development is not a democracy - and for those who are going to do get things done, discussion via IRC and its immediacy is a powerful tool. I personally think asking IRC not to be used for important (which is relative) decisions is not realistic. I do not think so. In the past, decisions that were discussed on IRC were informed by mail later or in bugzilla. Just to keep everybody interested in the loop and/or for archive purposes. At some point, we stopped doing it and, IMVVHO, is a bad practice. For instance, it is quite hard to explain and defend a decision when you only know the result (whether you personally agree or disagree). Do not confuse democracy with awareness. -- Germán Póo-Caamaño 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
GNOME community survey
FYI, A group of researchers leaded by Jim Herbsleb got in contact with GNOME Foundation some months ago in order to research how communities works, how a volunteer become an active contributor, among others. In the following days, developers (committers) will receive and invitation to complete a survey that would not take more than 20 minutes (or even less). However, the participation in the study is completely voluntary. It worth to mention that the results will be shared with the community, and we will insist on that. At last but not least, the original plan included a joint survey to help set the Foundation goals, which will not be the case. However, we are looking forward to receive help from this team of researchers in the near future. -- Germán Póo-Caamaño 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: GNOME community survey
On Fri, 2011-01-07 at 22:34 +0100, Christopher Roy Bratusek wrote: On Friday 07 January 2011 13:57:42 Germán Póo-Caamaño wrote: FYI, A group of researchers leaded by Jim Herbsleb got in contact with GNOME Foundation some months ago in order to research how communities works, how a volunteer become an active contributor, among others. In the following days, developers (committers) will receive and invitation to complete a survey that would not take more than 20 minutes (or even less). However, the participation in the study is completely voluntary. It worth to mention that the results will be shared with the community, and we will insist on that. At last but not least, the original plan included a joint survey to help set the Foundation goals, which will not be the case. However, we are looking forward to receive help from this team of researchers in the near future. Since people from Others section also got the invitation (like me), I wonder, whether the results of the questions regarding making GNOME better and the effort taken into GNOME may become a bit inapropriate, as those aren't actually doing that (their software is not shipped with GNOME). Or does GNOME in this case mean GNOME + software meant for GNOME-using people? Just wondering. I do not know what do you mean by Others, but if you got an email is because you have contributed with GNOME (considering the software under gnome.org). -- Germán Póo-Caamaño 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: GNOME community survey
On Fri, 2011-01-07 at 04:57 -0800, Germán Póo-Caamaño wrote: FYI, A group of researchers leaded by Jim Herbsleb got in contact with GNOME Foundation some months ago in order to research how communities works, how a volunteer become an active contributor, among others. In the following days, developers (committers) will receive and invitation to complete a survey that would not take more than 20 minutes (or even less). However, the participation in the study is completely voluntary. It worth to mention that the results will be shared with the community, and we will insist on that. At last but not least, the original plan included a joint survey to help set the Foundation goals, which will not be the case. However, we are looking forward to receive help from this team of researchers in the near future. I have received complains about specific questions, which only affect developers who have selected the option: Most of my income comes from doing software development for a company. For some miscommunication problem, I was not aware that option would lead to extra questions related to the employer. Hence, I could not review them and I can not endorse them. The most problematic questions are employer's name and the 4 questions related to intentions of moving to another company/job. I apologize for any inconvenience this issue might have produced. -- Germán Póo-Caamaño 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: Can you help me to merge your avatars?
On Wed, 2010-11-24 at 10:18 +0100, Mathieu Goeminne wrote: Hello, Thanks for your very precious and rapid feedback. I talked to my PhD supervisor, Professor Tom Mens about it (head of the software engineering group of the university, in CC of this mail), and he proposed to sign a non-disclosure agreement in which we promise not to make available the information about the physical persons involved (or the identities and logins they use). For our research purposes, the results we will produce will not contain any personal information.Essentially, our results will be primarily numerical and visual results that will be analysed statistically. We will ensure to respect any privacy policy that will be imposed. Concerning your second remark about git.gnome.org, we already use the guidelines you suggest, but they are not sufficient for our analysis purposes, since we still find quite a number of false positives and false negatives during our data analysis, and moreover this data does not contain information about identities used by the maillers and bug trackers. What do you mean for false positives and false negatives? (Not in the statistical definition, in the samples). You can always apply Pareto here: 80% of the code is written by 20% of the total of contributors. And for all of them, it is not hard to fix them (it is harder when you are not used to contributors in the project, but not that hard anyway). You will face bigger problems when mining GNOME git repositories, and you might double/triple count contributions in particular repositories (specially in the Subversion's era). You will find some huge commits with no new code at all (thousands of line of code), or the same history repeated across several repositories with different hashes, and so on. Our goal is to have a really unified view on the different data sources used during OSS development (committers, bug trackers, mailers), which is why the information contained in your LDAP will be very useful to us. Of course, we do not need *all* the information stored in the LDAP, only the information that will allow us to link identities to real persons. (Things like passwords and so on are entirely irrelevant for us, of course.) Peter Rigby has worked in unifying committers and mailing lists, and -as far as I know- he used some techniques proposed by Chris Bird (I do not have the reference at hand, but you will find them). Regards, -- Germán Póo-Caamaño 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: New module proposal: LightDM
On Fri, 2010-10-22 at 09:55 +1100, Robert Ancell wrote: On 21 October 2010 21:17, Sam Spilsbury smspil...@gmail.com wrote: Just a few things to note: - It seems to spawn about 4 or 5 server instances before it actually gets to your session. Is this intended? No, the lightdm server should only have one instance. - LightDM doesn't appear to pull in your gtkrc or anything from gnome-settings-daemon (eg a11y properties and the like). Will this be resolved? In the greeter or the user session? The greeter should be ally compliant(TM). Is it? -- Germán Póo-Caamaño 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: GNOME Moduleset Reorganization vs. L10N
On Sat, 2010-10-16 at 15:53 +0200, Vincent Untz wrote: Le vendredi 15 octobre 2010, à 17:02 +0200, daniel g. siegel a écrit : On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. We should improve our infrastructure if possible, sure. But it's a fact that there will be GNOMEy stuff not hosted on gnome.org, whatever we do. So we'll have to find a solution for this anyway. Let's not think that the whole world is wrong, and that we should host everything. Let's be pragmatic and accept that people might have different opinions on what is the best infrastructure :-) True, but as several people has already said hosting a project in our infrastructure was exciting 8 years ago, but now it is closer than a pain than an excitement. Old-time contributors know how to deal with them, where to ask, where to push, or have access to do it by themselves, etc. but for new contributors it is like offering to host webpages in geocities when there are better choices like wordpress.com, which looks nicer and makes the cooperation easier. FWIW, I like Gil's idea. -- Germán Póo-Caamaño 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: Statistics on each release
On Thu, 2010-07-01 at 14:21 -0300, Jonh Wendell wrote: Hello guys, I just read a xorg release announcement and found quite interesting their statistics not only about people but also about companies behind committers: http://lists.x.org/archives/xorg-devel/2010-July/010706.html Wouldn't be nice to have this in GNOME releases? :) Indeed. But there are some differences and it requires a bit more work. It is easier to run gitdm against Linux or Xorg or Python or OOo or whatever because there is *one* 'module' involved. But in GNOME we have dozens of modules involved, so it is required to consolidate the data. -- Germán Póo-Caamaño 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
[Reminder] Deadline for GUADEC travel assistance applications is due on April 27th
Dear hackers, The deadline for sending your GUADEC travel assistance application is due on April 27th, 19:00 UTC, that is in 14½ hours from now. The instructions are detailed at http://live.gnome.org/Travel Kind 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, 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
Travel assistance applications to attend to GUADEC
Dear hackers, The GNOME Foundation provides travel sponsorships to individuals that want to attend GUADEC and need financial assistance. We are happy to announce the Travel Committee is ready to receive applications for sponsorships to attend to GUADEC 2010. This year, GUADEC is being held in the The Hague University, in The Hague, Netherlands, from Monday 26th July, until Friday 30th July. The instructions are detailed at http://live.gnome.org/Travel Please read them carefully. Deadline: April 27, 2009, 19:00 UTC. You can start sending your applications now! Some additional comments: * Any information you send to the Travel Committee will be private. * Asking for sponsorship *does not* guarantee you will get sponsored. * A good application with good information will be processed faster. * If you need help with accommodation, the Travel Committee will book the hotel or hostel for you. This enables us to get group rates and provide accommodation assistance to the most people possible. You should state that you need accommodation, and leave the cost blank. * Always choose the most economical option whenever possible. People who need travel sponsorship, should look for the best price (i.e. through a service like kayak.com). If the Travel Committee finds a cheaper price, that will be the price considered during the evaluation. * If you are applying to a Google Summer of Code program (as student or mentor) you should mention it in your application. Preference will be given to students and mentors participating in the Google Summer of Code or the Outreach Program for Women. GSoC students usually get a percentage of their GUADEC expenses covered. * If you submitted an abstract to be presented at GUADEC, you should mention it in your application. Preference will be given to people giving presentations at GUADEC. The GUADEC paper committee will let the travel committee know which talks have been accepted, so as long as you let us know you submitted one, there is no need to follow up. * The Travel committee should reply back about receiving your application within 2-3 days. After that we would accumulate all the sponsorship requests and process them together. So please do not panic (have any butterflies in your stomach) if we take some time to reply on the status. Affirmative/Negative you would surely get a response. * No personal emails. Please keep travel-committee Cc'ed on all your replies. You can find us in the #travel channel at irc.gnome.org. Kind 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: Branch notifications
On Thu, 2009-11-26 at 07:03 +1100, Danielle Madeley wrote: On Wed, 2009-11-25 at 13:03 -0600, Shaun McCance wrote: The only potential problem is that the emails come from your username @src.gnome.org. I know sha...@gnome.org gets to my inbox, and I think sha...@src.gnome.org does as well. But do we have proper aliases set up for everybody who has git access? Could you simply use the email in the commit instead? I think Shaun refers to that email. In order to get an idea, you can take some modules and try something like: $ git log --pretty=format:%cd %ce %ae | grep \.gnome.org You will find a lot of (svn|src).gnome.org emails from authors and committers. 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: New module proposal: tracker
On Tue, 2009-08-18 at 18:35 +0200, Lennart Poettering wrote: On Tue, 18.08.09 16:11, Colin Walters (walt...@verbum.org) wrote: On Tue, Aug 18, 2009 at 3:32 PM, Jamie McCrackenjamie.mccr...@googlemail.com wrote: we could use the Gtk Recent files stuff for this and that would work for ordinary users but not devs fetching source code or other command line stuff Unless it's really REALLY compelling and fast, I don't want my source code in any kind of database, at least by default. We should leave this to IDEs. Hmm, I'd personally love if I had my own little google codesearch that could quickly tell me where I already used a specific API call and how I did it. My emacs doesn't offer me that unfortunately. I do no use emacs, but I guess emacs must have a way to talk to cscope. -- 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: git and trailing whitespace
On Wed, 2009-05-06 at 10:40 +0100, Bastien Nocera wrote: On Wed, 2009-05-06 at 11:18 +0200, Loïc Minier wrote: On Wed, May 06, 2009, Lennart Poettering wrote: I just have these lines in my ~/.emacs: (autoload 'nuke-trailing-whitespace nuke-trailing-whitespace nil t) (add-hook 'write-file-hooks 'nuke-trailing-whitespace) This sounds like it would remove all trailing whitespace in any file you touch; that sounds like a pretty bad idea for thinks like blame and will probably generate huge diffs for small changes -- or is this only about new code you're writing? I use vim and it displays trailing whitespaces as blue dots for me: set list set listchars=tab:-,trail:.,extends:,precedes:,nbsp:% (the relevant config above is trail:.; I find the other ones useful as well) Eek. That'd look bad. I believe this line is from Xavier's vimrc: set listchars=eol:•,tab:↦\ ,trail:»,extends:↷,precedes:↶ Another alternative is just highlight them in red. highlight BadWhitespace ctermbg=red guibg=red if has(autocmd) autocmd FileType c,cpp syntax match BadWhitespace /\s\+$/ endif -- 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: fast-forward only policy
On Wed, 2009-05-06 at 23:26 +0300, Felipe Contreras wrote: On Wed, May 6, 2009 at 2:04 PM, Ross Burton r...@burtonini.com wrote: On Wed, 2009-05-06 at 12:27 +0200, Vincent Untz wrote: Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : Debian patches are debian patches, they control them, and they make debian releases. If GNOME decides to remove those commits the distributions will not loose their patches. I think this summarize well the whole thing: we do not want to remove commits. Agreed. All the way through this thread I've been wondering what possible reason there would be for throwing away a commit on a historical branch. It's not about throwing away commits, it's about throwing away unused branches. I've already explained two ways in which the branches can be thrown away without loosing the commits although personally I would just throw the commits away. My feeling is that if GNOME were using git at the time of those legacy commits where made, the people developing them would have kept the changes locally, and by this time, the commits would have been thrown away anyway. In practice there's no difference between throwing away local commits and throwing away public commits that nobody will use. They are used by software archeologist's, for mining purposes. It is part of the project's history, and you should never regret of your history. -- 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: fast-forward only policy
On Wed, 2009-05-06 at 00:33 +0300, Felipe Contreras wrote: On Tue, May 5, 2009 at 11:55 PM, Olav Vitters o...@bkor.dhs.org wrote: [...] That's just how git works: branches and tags are mere pointers. There's no difference in the object storage, the only difference is logical, you use branches in a way, tags in another way. You can do stuff like: git update-ref refs/heads/foobar 68b2aee # creates foobar branch git update-ref refs/tags/foobar 68b2aee # creates foobar tag git update-ref refs/taggybranch/foobar 68b2aee # creates foobar weird ref Are you assuming that all changes in stable branches get merged in development branches? How should it work the following development? a--a---a---a---a (2-20) +---b---b---b---b---b (2-22) +---c---c---c---c---c---c (2-24) +---d---d---d---d---d---d---d--... (master) If delete the branch 2-22 I will loose the latest 3 commits, same for 2-20, and so on. 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
Extended deadline for GUADEC's travel sponsorship applications
Dear hackers, The deadline to apply for travel sponsorship in order to attend to GUADEC has been extended. Applications will be received until April 30, 2009, 19:00 UTC. Instructions about the process can be read at http://live.gnome.org/Travel Kind 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
Reminder: Travel assistance applications to attend to GUADEC
Dear hackers, The Travel Committee is receiving applications for travel sponsorship requests for the next GUADEC which will be held in Gran Canaria, Spain. The deadline is April 27, 2009, 19:00 UTC. Do no wait until the very last minute. Read carefully the instructions and the process' explanation at http://live.gnome.org/Travel Kind 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: On autogenerated ChangeLog
On Mon, 2009-04-20 at 12:17 -0400, Dan Winship wrote: Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want tSysadmins, Package maintainersmo actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). But that doesn't answer the question. Who are these people who read ChangeLog, and what is it that they're doing with it, such that NEWS is too brief, but a fully-VCS-ed source tree is unnecessary. Eg, this subthread started when Alex suggested that we needed to put the names of all modified files into each ChangeLog entry. It seems to me that anyone who cares exactly which files got modified by a particular change is going to want to see the actual diff very soon after, and so those people are not actually part of the don't-need-a-full-checkout use case. But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Sysadmins and they take the decision if it worth an update/upgrade or when they should do it. If we ask people to read ChangeLogs from git, I wonder why do we bother in releasing tarballs when they could them from the repository also? (in the sense you can get a tar.gz/tar.bz2, they are tagged, etc.) -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Nettool branched
I just branched gnome-nettool. The new development will be held in trunk, while the latest stable branch is gnome-2-26. -- Germán Póo-Caamaño Concepción - Chile http://www.calcifer.org/ 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: Reduced Bugzilla functionality for 6+ months -- acceptable?
On Thu, 2008-12-04 at 18:19 +0100, Andre Klapper wrote: but please focus on what you use: Is the reduced functionality trade-off acceptable if in the end we get a newer Bugzilla and the feature back? Note that likely some things will work in different ways etc. As long as stock answers and simple-dup-finder functionality get a high priority so they will be provided again asap, this all sounds totally fine to me. Looking forward to get most of GNOME's beautiful modifications upstreamed. IMVHO and as far as I saw in the code, stock answers should be the quickest feature to be re-added. (where I work we use Gnome Bugzilla with our own customizations, and also I've been looking how to upgrade, but also I'm looking to move from MySQL to Postgresql). -- 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: DVCS
On Tue, 2008-10-28 at 15:10 +, John Carr wrote: [...] bkor isnt the only sysadmin, but who are the others and how much do they do.. the whole sysadmin process is not very transparent. Shouldn't it be? I would *love* to help out the sysadmins, maybe even offer them some of my time. Where is it documented on how to be considered as a sysadmin? Even a junior sysadmin that can just set up mailing lists and do svn imports... I hang around #sysadmin but there is only so much i can suggest people try before i have to leave them to the irc gods http://sysadmin.gnome.org/helping.html -- 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
Request for update external dependency
Dear Release Team, At this moment of our schedule, gnome-2.24 module sets as external dependency fontconfig-2.5.0, which was the first release of a development version. At the end of May 2008, freedesktop had released the new stable version, fontconfig-2.6.0.tar.gz. The external dependency currently is fontconfig 2.4.1 (as is written in http://live.gnome.org/TwoPointTwentythree/ExternalDependencies). However, jhbuild has set 2.5.0 which its configure's argument '--disable-docs' doesn't really work. 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: GDM version used for GNOME 2.24?
-> Re: GDM version used for GNOME 2.24? desktop-devel-list -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: GDM version used for GNOME 2.24? Germán Póo-Caamaño Re: GDM version used for GNOME 2.24? Diego Escalante Urrelo Re: GDM version used for GNOME 2.24? Mathias Hasselmann Re: GDM version used for GNOME 2.24? Mathias Hasselmann Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Willie Walker Re: GDM version used for GNOME 2.24? Matteo Settenvini Re: GDM version used for GNOME 2.24? Alberto Ruiz Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Ray Strode Re: GDM version used for GNOME 2.24? Patryk Zawadzki Re: GDM version used for GNOME 2.24? Kjartan Maraas Re: GDM version used for GNOME 2.24? Brian Cameron Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Diego Escalante Urrelo Re: GDM version used for GNOME 2.24? Mathias Hasselmann Re: GDM version used for GNOME 2.24? Mathias Hasselmann Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Willie Walker Re: GDM version used for GNOME 2.24? Matteo Settenvini Re: GDM version used for GNOME 2.24? Alberto Ruiz Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Ray Strode Re: [gdm-list] GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Patryk Zawadzki Re: GDM version used for GNOME 2.24? Kjartan Maraas Re: GDM version used for GNOME 2.24? Brian Cameron Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Diego Escalante Urrelo Re: GDM version used for GNOME 2.24? Mathias Hasselmann Re: GDM version used for GNOME 2.24? Mathias Hasselmann Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Willie Walker Re: GDM version used for GNOME 2.24? Matteo Settenvini Re: GDM version used for GNOME 2.24? Alberto Ruiz Re: GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Ray Strode Re: [gdm-list] GDM version used for GNOME 2.24? Brian Cameron Re: GDM version used for GNOME 2.24? Vincent Untz Re: GDM version used for GNOME 2.24? Patryk Zawadzki Re: GDM version used for GNOME 2.24? Kjartan Maraas Re: GDM version used for GNOME 2.24? Brian Cameron Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792&quo
