I’m planning to stay at the following hotel: Istanbul Hotel Ipek Palas. Some other crazy Dutch guys will be staying there too (so you don’t have to prepare a map or something.. just rely on them 😉 ). Need a roommate though, anyone interested? I’ll arrive Sun 6 and leave Sat 12. If so, mail me, or post below. The hotel has free wifi btw.
As seen in #sysadmin
<saned> hello. I'm wondering whether http://l10n.gnome.org/ has been defaced... <saned> it says "Damned Lies about GNOME" <saned> is it some kind of joke?
The question alone
Weird. I think that just thinking about something like that being possible is very weird. Planet GNOME is one of the aggregators which shows every post, always (a full feed is often requested). The only exceptions (AFAIK) being: bugs, bugs and bugs (either planetplanet, GNOME server or when there is a server problem with the feed).
So to question the openness of GNOME Planet.. weird. I thought pgo had more trust than this. Wonder what can be done to change this impression.
I also don’t agree with:
Furthermore censorship on a service provided by those who consider themselves advocates of freedom and liberty is hypocritical to say the least.
Start a personal attack on a GNOME service and you can forget about mentioning freedom. Furthermore, freedom/liberty is to be able to announce something, not about being able to do that anywhere you please. Meaning: if GNOME provides a service, GNOME decides on what is allowed (but don’t forget about the beginning of this blog).
Lastly, I don’t see GNOME as an advocacy of freedom and liberty (just free software).
Git git git
Why is Git for some only the one perfect DVCS and no discussion is possible? From Git is the only DVCS caring about performance incl outdated benchmarks, to the ‘all DVCS’ systems are hard’ and lastly ‘switching VCS systems is easy’. Regarding the latter, who is going to do the conversion? I am fully willing to do Bazaar (perhaps Mercurial.. I’d first would have to investigate that). But Git? Even a ‘am I capable?’ would dismiss me from doing that. Anyway, from following the stuff before the CVS->SVN switch, to fixing loads of things afterwards, switching a VCS system not at all as easy as some make it out to be. Just the under estimation makes me worry.
When I see something which is broken, I cannot just leave it without trying to fix it (aside from lacking time and if I am able to, but ‘able’ is pretty easy with root access). From DNS stuff, to LDAP, accounts process (Mango), SVN repos creation, etc. Although I’d really love if more GNOME sysadmins would be active… anyway, if Git is considered to be the only option and the attitude regarding the ease of switching stays the same, I do not want to have the ability to fix whatever was forgotten or broken.
Bzr vs SVN
I wanted to rewrite Mango in Python for a while now, but couldn’t determine which framework to use. Mostly as these frameworks either do way too much or just not enough. Shaunm (and some others in #gnome-hackers) was so nice to convince me that Django was a really good framework. This as I hate frameworks. I want to ignore most of it. My basic needs were CSRF protection (not that I cannot do it myself, but I want to ensure they’ve thought about security), session, something like fastcgi/scgi (the Mango Python stuff needs to run under a different user) and templates etc should be optional.
For the rewrite I’ve decided to use the Bzr mirror. This while still publishing the branch on svn.gnome.org and having the ability to merge both ways (from trunk to django and django to trunk.. at one point). The initial setup for the tools I needed took some time, hopefully this will be resolved soon. This as Mandriva doesn’t have a bzr-svn package yet. I started off with bzr-svn.
Installing bzr-svn is pretty easy (only needed to push to svn.gnome.org, pulling can be done via bzr-mirror):
mkdir -p ~/.bazaar/plugins/ cd ~/.bazaar/plugins bzr branch http://people.samba.org/bzr/jelmer/bzr-svn/bzr.dev/ svn
However, that plugin wants the right Subversion version and 1.5 wasn’t packaged for Mandriva Cooker yet. Compiling Subversion failed initially, as it somehow wanted to link to the installed subversion libraries (this while I did not have the 1.4 svn devel package installed). After I figured that out, there was another issue as the Subversion API changed with 1.5. The workaround for now is to remove the assertion on line 944 in subversion/libsvn_ra/ra_loader.c (or wait for the new bzr-svn plugin).
After getting the tools working, the rest is a bit magical. I followed the GNOME Bazaar instructions and branched Mango trunk locally in a django branch. A bzr push svn+ssh://svn.gnome.org/mango/trunk would be enough to push it back to GNOME (you need to specify the push URL once). However, I wanted a branch in SVN. The push command currently (?) will not create new branches, but there is a svn-push which does.
The command I used to create the new ‘upstream’ branch was:
$ bzr svn-push svn+ssh://svn.gnome.org/svn/mango/branches/django
The result from svn-commits-list:
Author: ovitters Date: Sat Jun 21 17:58:09 2008 New Revision: 205 URL: http://svn.gnome.org/viewvc/mango?rev=205&view=rev Log: Try and port the mess to Python using the Django framework. * .bzrignore: Ignore the django directory. * mango/manage.py: Standard Django script to manage the Django project. * mango/models.py: Describes the Database (needs a bit of work). * mango/settings.py: Django settings and the config.xml file. * mango/urls.py: Maps URLs to functions which will be called. * mango/views.py: Handles turning an http request into an http response (application/xml). Added: branches/django/ (props changed) - copied from r204, /trunk/ branches/django/.bzrignore branches/django/mango/ branches/django/mango/manage.py (contents, props changed) branches/django/mango/models.py branches/django/mango/settings.py branches/django/mango/urls.py branches/django/mango/views.py Modified: branches/django/ChangeLog
From above email it is clear it copied (branched) the trunk and not just put new files into that Django branch. The resulting test Django installation works pretty similar as the current PHP Mango version:
Oh, and some way too early screenshots:
Current trunk (PHP)
Django branch
It seems nice, but that is just because I am sharing the XSLT templates. It doesn’t do anything useful yet. For instance, you can clearly see the missing ‘tabs’ and that it doesn’t filter the account requests. A Django LDAP model would also be nice (has a really nice abstraction for models), but was designed with database in mind unfortunately.
Subversion 1.5
SUbversion 1.5.0 has been released. I plan to upgrade svn.gnome.org when 1.5.1 is released. See the announcement for full 1.5 details. Things I like are:
- Merge tracking
There are still a few known issues with this. This is why I want to wait until 1.5.1. - Sparse checkouts
- Relative URLs in svn:externals
Allows stuff like/svn/someotherproject/trunk. Avoids thehttpvssvn+ssh. - Memory leak fixed
There was a memory leak which caused problems for bzr-svn and others.
SVN dump+reload script?
I still have to dump/reload all GNOME repositories for the server to use the SVN 1.4 repos format. I’d appreciate if someone has a smart script for this to minimize any downtime (by doing the dump+reload in two stages, first stage dump+reload, 2nd stage disables permissions, dumps+reloads any commits done during the 1st stage, then moves over the 1.4 SVN in place, lastly enabling access again.. this per repository).
My post
I really love all those
HTML tags.Pre-commit hooks
Regarding:
This was more annoying, since there is some script there in s.g.o’s guts that rejects any commit if the repo has an executable.
This is a simplification. Executable files are allowed. There is a pre-commit hook to disallow executable .po files, but that check is only done for .po files added/changed by the commit. It does not check for other .po files. If you see otherwise, please contact svnmaster@gnome.org. Normally developers shouldn’t hit this check btw (only when you’re changing the .po file).
Getting stuff into GNOME
Just wanted to respond via the planet on one thing:
It is getting increasingly hard to get new stuff into Gnome, and when someone approaches with something that is slightly controversial huge flamewars erupt. Consider Tracker and Empathy on the desktop-devel list and the recent “incident” on the gtk-devel list.
Ignoring Tracker (too long ago and I’d rather see that standard used instead of deciding between Tracker/Beagle), I don’t think the other examples are good. For one, the gtk-devel list was not regarding getting new stuff into GNOME. Further, the flamewar started because the person was clearly trolling (I had to resort to moderating!). The idea itself did not cause the flamewar.
Empathy has a few issues (not using gnome-keyring and the license). This doesn’t support your statement. If those are fixed, I’d give a +1 during the r-t meeting. From the last time we discussed Empathy, I felt these two items was the only reason Empathy wasn’t accepted.
Every release cycle we accept a few things into GNOME. We do ask for a certain quality, e.g. making releases on time and responding to the incoming bugs. Sometimes a proposed module only made one release on time. We do look at future possibilities of a certain module (good enough and shows promise is what I look for), but the basics shouldn’t be ignored.
SVN.gnome.org back up
Note that the distribution upgrade of svn.gnome.org has been completed. AFAICS everything is working. If you have issues, please ping me (bkor) or another person with ops in #sysadmin (irc.gnome.org).
PS: I do expect loads of commits now 🙂