Re: Git: Do not use http to access Git!
On Thu, Feb 17, 2011 at 1:25 PM, Danielle Madeley danielle.made...@collabora.co.uk wrote: On Thu, 2011-02-17 at 10:48 +0100, Olav Vitters wrote: 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). Is it possible these people are on ridiculous corporate networks that only permit HTTP traffic (via a proxy) and allow no other outgoing connections beyond their network? I have been on one of these before, http was the only way I could checkout sources (from Subversion at the time). If this is the case, git being awesome as it is, perhaps someone could set up a remote that offers http cloning that updates once a day or so. This would let people clone a repo, and still submit their work via format-patch etc. I agree. That has happened to me as well. I understand the performance issues, but not to have a http acces to the clones, could be blocker issue for some people. Greetings. -- Juanje ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 2:56 PM, Jonh Wendell jwend...@gnome.org wrote: Hi, folks. Hi :-) We from Brazilian team are discussing about the best option to report bugs related with translations. An optimal solution is to have bug-buddy integrated into applications, in the menu Help-Report a bug or wish. This would call bug-buddy, the user would select the severity of the bug (translation, bug, suggestion), enter the bug itself and then would hit the 'send' button. Simple like that. Ubuntu does something similar, but the negative points are: - Ubuntu packagers have to patch lots of applications; - The bug reports go to launchpad, ubuntu only; - The launchpad interface is English-only, where bug-buddy is translated into the user language; Well. actually it is not exactly like that. Ubuntu has two menu entries for the help on each app to report things. * Report an error (apport) * Translate the application The error report is what you describe, but I think it's a bit better than you said. Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. It does generate very complete reports and send them as a Multipart/MIME so the server side can receive each log as a different attachment, which is very clear. It's made in python and is easy to add hooks[2] for applications to attach more logs or info to the report. And the tool is translated into several languages: http://translations.launchpad.net/ubuntu/jaunty/+source/apport/+pots/apport Anyways, this is very focused in crash or issues report. The other option takes you to the Ubuntu translation page for that application. But I guess it's just good for the Ubuntu translators, because it's not very easy for normal (non-English speaker) user to find how to fill a translation bug. We could redirect the user to a translation bug for the product of the application in our Bugzilla. Something like: http://bugzilla.gnome.org/simple-bug-guide.cgi?sbg_type=l10nproduct=l10napplication=hamster-appletcomp=Spanish [es] If I'm launching it from hamster-applet with Spanish locales. Perhaps bug-buddy could be configurable to send reports to another place instead of only bugzilla.gnome. I don't know how is now bug-buddy, but I remember that before was a bit hard for a newbie of non very tech people. Maybe now it's is more user friendly... Anyway, this is an interesting thing and wold be nice to have such a feature :-) Cheers [1] https://wiki.ubuntu.com/Apport [2] https://wiki.ubuntu.com/Apport/DeveloperHowTo -- Juanje ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Tue, Oct 28, 2008 at 3:24 PM, Zeeshan Ali Khattak [EMAIL PROTECTED] wrote: Hi everyone! I remember that at GUADEC, we were seriously thinking about migrating to git but the decision was postponed on Mark Shuttleworth's request. It's been some months since that and we are still stuck with SVN. AFAIK both git and bazaar have very strong supporters in our community so the only way I see out of this is: 1. Get someone (known and trusted) to volunteer to set-up and maintain the repository. I think Olav likes bazaar so he would volunteer for that? 2. Assuming that we get volunteers for both the repository types, we simply vote amongst the top 50 contributers (i myself most probably don't count :)) [...] Ummm... So, the discussion will be just about bazaar and git? What happend with Mercurial? I see the three of them on http://live.gnome.org/DistributedSCM If there was some earlier discussion about it were you decide to leave Mercurial out, just tell me, please. BTW, I think as well (as Claudio say) that should be the current SVN GNOME users (which fight against the SVN repo everyday) who might decide. Cheers -- Juan Jesús Ojeda Croissier Emergya Consultoría / http://www.emergya.es Avda. de la Innovación, 3 (Edif. Hércules), Mód 12-13 E41020 Sevilla Tfno: +34 954 51 75 77 Fax: +34 954 51 64 73 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Thu, Oct 23, 2008 at 5:15 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 5:08 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Thu, 2008-10-23 at 17:02 +0200, Frederic Peters wrote: A point Patryk touched is that generic distributions will provide Apache packages configured to run at startup, so it is not just a matter of binary size. That's exactly the problem. As a data point, Fedora's httpd is disabled by default for exactly this sort of reason (having it installed doesn't mean we want it running by default). I doubt our server guys will get overly happy over the idea of disabling a typical server daemon just so you can integrate it with GNOME. I don't really think I want the server team to hate the GNOME team any more. Also there seem to be lighter alternatives: http://www.perlmonks.org/?node_id=658773 And what about Cherokee? http://www.cherokee-project.com It's small, modular, very light and easy to run as a user in specific port (to avoid bother system web servers, for example) http://www.cherokee-project.com/doc/bundle_cherokee-worker.html -- Juan Jesús Ojeda Croissier Emergya Consultoría / http://www.emergya.es Avda. de la Innovación, 3 (Edif. Hércules), Mód 12-13 E41020 Sevilla Tfno: +34 954 51 75 77 Fax: +34 954 51 64 73 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.24 Showstopper Review
On Mon, Sep 1, 2008 at 3:00 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: On Mon, Sep 1, 2008 at 2:57 PM, Og Maciel [EMAIL PROTECTED] wrote: On Mon, Sep 1, 2008 at 8:04 AM, Sebastian Pölsterl [EMAIL PROTECTED] wrote: In my opinion an additional blocker is that hamster applet requires Python 2.5 [1]. It might be just a change in configure.ac if they don't make use of any Python 2.5 specific features. Last time I checked, it did. :/ Care to share the details in the bug report? As much as I'd want to fix it, I don't (and won't in the foreseeable future) have access to any pre-2.5 machine. Toms fix it just a moment ago. There where a couple of Python 2.5 specific features, once they where changed it was just matter of change the python version on the configure.ac. So this bugs is not blocking any more :-) -- Juan Jesús Ojeda Croissier Emergya Consultoría / http://www.emergya.es Avda. de la Innovación, 3 (Edif. Hércules), Mód 12-13 E41020 Sevilla Tfno: +34 954 51 75 77 Fax: +34 954 51 64 73 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
