Die “123gold Trauring-Lounge Graz” hat am 1. März 2011 ihr Geschäft eröffnet. Das kam gerade recht für das Event des Jahres und so haben meine Liebste und ich uns dort nach einem passenden Paar Trauringe umgesehen. Die Verkäuferin Frau S. wirkte nervös und chaotisch aber freundlich und bemüht, so haben wir die etwas chaotische Beratung in Kauf genommen.

Unsere gewünschten Ringe wurde bestellt und waren rechtzeitig für das Event zur Abholung bereit. Die Ringe waren ein wenig zu groß, aber da uns versprochen wurde, dass eine Verkleinerung des Ringes für 25€ möglich ist und wir uns ob der Größe einfach unsicher waren, war uns das in dem Moment egal. Marianne war der Ring schließlich für den Alltagsgebrauch ganz klar zu groß und daher hat sie sich nach der Hochzeit auf den Weg in das Geschäft gemacht. Doch auf einmal hieß es, dass die Verkleinerung in ihrem Fall doch mehr kostet als angekündigt, weil wegen des eingesetzten Diamantes der Ring neu eingeschmolzen werden muss. Sie ging zur Konkurrenz ums Eck – dem Juwelierladen Weikhart – und dort wurde ihr gesagt, dass der Ring ganz klar um 2 Nummern zu groß ist, aber die Anpassung leider nicht von Weikhart durchgeführt werden kann, da der Diamant-Einsatz eine spezielle Behandlung durch den Hersteller/Produzenten benötigt. Marianne hat in den sauren Apfel gebissen und sich den Ring bei der Trauring-Lounge kleiner machen lassen.

Auch mein Ring war zu groß, besonders bei kalten Fingern war es störend. Ich habe aber erst später den Weg in die Trauring-Lounge geschafft. Unsere damalige Verkäuferin war dann leider nicht mehr anzutreffen. Der erste Hammer kommt aber sofort: die Verkäuferin gibt mir falsche Modellringe zum Probieren in die Hand, denn innen sind diese komplett anders geformt als mein Exemplar. Das ist genau das, was sich im Nachhinein als der Grund für die falschen Ringgrößen herausstellte. Nach meinem diesbezüglichen Hinweis habe ich dann zwischen zwei Modellen der richtigen Passform entscheiden müssen. Die Variante die zwei Nummern kleiner war als mein Ring kam mir eine Spur zu klein vor, die größere Variante wiederum kam mir zu locker vor. Die Dame konnte mir aber meine Entscheidung nicht leichter machen (im Gegenteil, mit dem Hinweis auf die Option einer Zwischengröße hat sie mich noch weiter verunsichert). So habe ich mich erst mal nach den Kosten für die Anpassung erkundigt. Nach meinem Hinweis darauf, dass wir bereits ursprünglich beim Kauf schlecht beraten wurden – denn auch damals bekamen wir nicht die zu unserem Modell passenden Proberinge zum Probieren – bot mir die Verkäuferin einen Preisnachlass um 10€ an. Doch sollte es jetzt statt der ursprünglich versprochenen 25€ auf einmal 35€ pro verkleinerter Größe – sprich 70€ für 2 Größen kleiner – kosten. Die 60€ empfand ich als Hohn und als letztes Angebot wurde mir noch eine Anpassung um 35€ angeboten. Daraufhin habe ich den Laden verlassen um mir in einem anderen Juwelierladen ein Angebot einzuholen.

Im Juwelierladen Weikhart gleich auf der anderen Seite vom Hauptplatz habe ich daraufhin die Situation geschildert und bekam eine äußerst kompetente und freundliche Beratung. Im Vergleich zur Trauring-Lounge wurde mir die Entscheidung für die Größenwahl leicht gemacht, denn die Verkäuferin hat mir den Ring – ganz im Gegensatz zur Konkurrenz – nicht nur auf den Finger gesteckt, sondern auch “herumprobiert”. Es wäre eine ganz klare Angelegenheit: 2 Nummern zu groß. Aufgrund einer ungewöhnlichen Legierungsart wurde auch sofort Rücksprache mit dem Goldschmied gehalten, ob die Änderung denn auch möglich sei. Ich könnte den Ring am nächsten Tag abholen, da der Aufwand aber aufgrund der ungewöhnlichen Legierung noch nicht abschätzbar sei können sie mir noch nicht garantieren, wie viel es ausmachen würde. Als Preisbereich wurden 10 bis 25€ genannt. Für mich war die Entscheidung damit natürlich eine klare Sache. Keine vier Stunden später erhalte ich bereits den Anruf, dass ab sofort mein Ring abgeholt werden kann. Das habe ich dann auch getan, und gezahlt habe ich dafür 10(!) Euro.

Der direkte Vergleich der Beratung war wie Tag zu Nacht, von den Kosten ganz abgesehen. Da man Trauringe üblicherweise nur einmal im Leben kauft können wir unsere Geschichte nur teilen, was hiermit getan sei. Unser Fazit und was ihr daher bitte wissen und weitererzählen sollt:

tl;dr: Finger weg von der 123gold / Trauring-Lounge Graz

Die Suche nach Vorträgen und Projektständen wurde soeben offiziell eröffnet. Wenn du ein spannendes Thema oder Projekt hast, über das du vor einem interessierten Publikum reden möchtest ist das deine Chance.

Die Grazer Linuxtage feiern heuer ihren 10. Geburtstag(!) und wir erwarten auch diesmal wieder mehr als 500 Besucher auf einem der größten IT-Events in Österreich.

Disclaimer: Die Grazer Linuxtage sind für ein buntgemischtes Thema bekannt. Wir beschränken uns aber weder auf Linux, noch mußt du dir ein supertechnisches Thema aussuchen. Von Anwendersoftware und Projektvorstellungen, über Themen für Systemadministratoren und Softwareentwickler, bis hin zu freier Kultur und Technik ist alles mit dabei. Ganz besonders freuen wir uns über Vorträge für Einsteiger (du musst definitiv kein Superduperüberdrüber-Geek sein um bei uns vorzutragen – weder wir noch unser Publikum beißen!).

Wir freuen uns über deine Vortrags- und/oder Projektstand-Einreichung über Linuxtage.at.

I’ve been using git-svn to handle the FAI svn repository for at least as long as I’m wearing the FAI stable release manager hat. But the tags, author information,… inside my git-svn checkout weren’t ready for official publishing yet…

There are at least two different well known and referenced svn2git implementations out there. I decided to give the one hosted on github a shot because it’s mentioned at http://help.github.com/import-from-subversion/. It basically uses git-svn and just does the few annoying steps for you that I’d had to do manually otherwise. For more complex repositories the other svn2git implementation might be worth a try, especially since it’s supported by the svneverever tool. svneverever supports more flexible rules regarding the repository layout (it was used for switching Gentoo’s Portage from Subversion to Git). Luckily we didn’t need it in our situation and I had experience with git-svn on the FAI repository already, so…

Converting the repository was as simple as running:

% svn2git svn://svn.debian.org/svn/fai --authors ../fai-svnauthors

The ../fai-svnauthors file contains all the “svnuser = Realname <mail@example.org>” mappings to get the author information right. Some 41 minutes later svn2git finished its work. Finally I pushed the result to the FAI repository at github.

If you’re interested in the repository size of svn vs. git:

• svn repository (server side): 155MB
• svn checkout (client side): 318.3MB (4.3MB trunk, 301MB tags, 13MB branches)
• git-svn checkout: 13MB
• git repository/checkout: 7.1MB

This embedded video doesn’t work for you? Try heading over to YouTube.

Since its my first screencast please let me know what you think of it. Waste of time? Want to see further screencasts about Zsh, Grml,…? Is there any other platform than YouTube better suited for such screencasts (for the creator as well as the visitor’s point of view)? Is there anything specific I might consider changing in upcoming screencasts?

• Apache
• Bazar
• cocos2d-x
• ConfigureMe/DistributeMe/MoSKito
• coreboot
• Creativecommons
• Django CMS
• Doom Port Build Service
• Eclipse Communication Framework
• Freeswitch
• Grml
• iceScrum
• JBoss
• Jenkins
• JMRI
• JRuby
• KDE
• Linaro
• Mahara
• Mozilla
• Nuxeo
• OpenQuake
• Pentaho
• Piwik
• Plone
• PODAM
• Pylons Project
• Saiku
• Scala-Tools
• SQLAlchemy
• SQLAlchemy-migrate
• Tapestry 5 modules breadcrumbs + tagselect
• TYPO3
• UTGB (University of Tokyo Genome Browser) Toolkit
• Wicket Stuff
• Zikula

Open source projects using Jenkins, though Jenkins service not accessible for the public (yet):

• Evolvis
• Fusionforge
• Icinga
• Joomla
• OpenJDK 7 for OS/X
• Openstack
• sip:provider CE

And Cloudbees hosts some OSS projects providing Jenkins as a service.

Update [2011-09-05]: I put the list to the jenkins wiki under https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins -> https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=58001258

Update [2011-08-29]: thanks for all the feedback, I’ve updated the list accordingly.
If you’re aware of another open source project using Jenkins please leave it in the comments, I’ll update the list accordingly then.

On 19th of August 2011 there have been:

• 16935 unique source packages in Debian/sid
• 9977 packages with Vcs-* field in Debian/sid
• 6957 packages without a Vcs-* field in Debian/sid

Therefore ~59% of all packages in Debian/sid are officially managed with a version control system (VCS). Now, which VCS do those packages use?

1. Svn: 4939
2. Git: 4377
3. Darcs: 284
4. Bzr: 247
5. Hg: 61
6. Cvs: 31
7. Arch: 28
8. Mtn: 10

I’ve retrieved the numbers from the Ultimate Debian Database (UDD). Sadly there’s a bug in UDD regarding the Vcs-Type information, see #637524. Therefore I’ve extracted a list of 80 packages where a Vcs-Browser header is available but the Vcs-Type entry is empty in UDD. 29 packages of them are managed inside CVS but don’t appear as such in UDD, so I manually corrected the number for CVS in the numbers above. The remaining 51 packages have a Vcs-Browser field set but lack the according Vcs-* entry, some of them pointing to upstream VCS instead of the according Debian package repository, some of them result in 404 errors, etc. As a result I’ve reported bugs where applicable (#638466, #638468, #638469, #638470, #638471, #638472, #638474, #638475, #638476, #638477, #638479, #638482, #638486, #638488, #638493, #638497, #638501, #638475, #638475, #638502, #638503, #638505, #638506, #638508, #638509, #638510, #638511, #638512, #638513, #638516, #638518, #638519, #638520, #638522, #638523, #638524, #638525, #638526, #638527, #638528, #638529, #638530, #638516, #638531).

Disclaimer: I found Debian’s Statistics wiki page and Zack’s VCS usage stats after starting to play with my own stats. AFAICT Zack’s slightly higher numbers are the result of looking at multiple versions for the same source packages, as you’ll see when comparing numbers from UDD’s sources_uniq view (which I used) with either 1) UDD’s sources table, 2) source table count from projectb or 3) Package count from http://$DEBIAN_MIRROR/debian/dists/unstable/{main,contrib,non-free}/source/Sources.bz2.

Conclusion: 9316 packages are officially managed with Subversion and Git as of today, representing ~94% of the VCS managed packages. This means ~55% of all the Debian (source) packages are available through either a Git or Subversion repository – and that’s actually the number I was originally interested in.

Thanks to Alexander Wirt, Christian Hofstaedter, Gerfried Fuchs, Jörg Jaspert and Michael Renner for hints in forming up the final stats results.

Ich habe soeben “Das Git-Buch – Verteilte Versionsverwaltung für Code und Dokumente” von Valentin Haenel und Julius Plenz gelesen. Das deutschsprachige Buch füllt 328 Seiten und konkurriert mit freien Büchern wie dem Git Community Book, Pro Git und Git In the Trenches. Das Inhaltsverzeichnis des Buches sieht wie folgt aus:

1. Einführung und erste Schritte
2. Grundlagen
3. Praktische Versionsverwaltung
4. Fortgeschrittene Konzepte
5. Verteiltes Git
6. Workflows
7. Git auf dem Server
8. Git automatisieren
9. Zusammenspiel mit anderen Versionsverwaltungssystemen

Es geht schnell zur Sache: die fürs Verständnis besonders wichtigen Themen Index und Objektmodell sind bereits nach rund 60 Seiten solide absolviert. Bei dickeren Büchern habe ich immer Angst, dass die Seiten mit Auszügen aus Manpages oder Kommandozeilenoutput gefüllt sein könnten, das ist aber hier definitiv nicht der Fall. Die Erklärungen sind knackig und präzise geschrieben, es wird nicht lange um den heißen Brei geredet.

Es gibt anschauliche Beispiele und es wird nicht nur das wie erklärt, sondern auch das warum und was der Hintergrund von einem anfangs vielleicht noch komisch anmutendem Konzept ist. Fortgeschrittene Themen wie reflog und filter-branch werden praxisnahe behandelt und auch meine Lieblinge wie –color-words, interaktives Rebasen, git grep und cherry-picking kommen vor.

Ich habe einiges dazu gelernt, wie z.B. ‘git show id:datei’, ‘git gui blame’, den Einsatz von ‘git rerere‘ und wie man eine GPG-Signatur in einen Blob steckt. Dass die sehr nette patch-Option ‘-p’ in vielen Tools funktioniert war mir bereits bekannt, dass die verbose-Option ‘-v’ aber etwa beim Commiten nützlich sein kann war mir neu. Der Hinweis auf mergeinfo-Support in git-svn mit Git Version 1.7.4 kam mir ebenso wie die Gegenüberstellung von Submodules zu Subtrees gerade recht.

Zu Beanstanden habe ich nur eine Kleinigkeit: Im Absatz über gute Commit-Nachrichten fehlt mir ein Hinweis auf englischsprachige Commit-Nachrichten als empfehlenswerter Standard. Das Buch richtet sich natürlich an deutschsprachiges Publikum und daher sind die deutschen Commit-Nachrichten in den Beispielen verzeihbar, aber deutschsprachigen Commit-Nachrichten möchte zumindest ich in keinem Repository begegnen, an dem mehrere Personen beteiligt sind.

Aus der Stichwortliste was ich gerne erwähnt gefunden hätte sind folgende Punkte offen geblieben: das praktische Tool git-wtf, das Konsolenfrontend tig sowie der mit speziellen Tools versehene Workflow gitflow. Zu git-svn fällt mir noch die addAuthorFrom/useLogAuthor-Thematik ein. Sehr praktisch für den Alltag finde ich weiters url insteadOf/pushInsteadOf. Im Kapitel zu Github hätte vielleicht noch ein Hinweis auf eines der hilfreichen Tools wie git-pull-request Platz gehabt. Dass Tools wie git-buildpackage und gitpkg im Debian-Paketbau beliebt sind und diverse Frontends für Emacs und Vim existieren hätte aber vermutlich das Buch inhaltsmäßig gesprengt oder das Risiko mit sich gebracht, dass die Informationen für ein Buch zu schnell überholt sein könnten.

Mein Fazit: Selbst mit über 3 Jahren Erfahrung und als Anhänger von Git hat mich das Buch nicht gelangweilt, sondern das vorhandene Wissen gefestigt und neues dazugestellt. Das Buch liefert solides Wissen in angenehm lesbarer Form und ich kann es Einsteigern wie Fortgeschrittenen empfehlen. Man hat damit den passenden Überblick und die richtigen Stichwörter um sich durch die diversen Manpages und die Weite des Internets zu kämpfen und Git voll genießen zu können.

Disclaimer: Ich habe vom Verlag ein kostenloses Exemplar zur Verfügung gestellt bekommen.

Looks like I suffer from presentation driven development, so the notes turned out to become bigger than expected. If you’re interested in my Zsh pony then head over to grml.org/zsh-pony.

PS: I plan to provide the zsh pony at github, but my org-mode file still causes an error 500 at github. Github support is already aware of it. In the meantime I’m happy to receive feedback, patches and contributions via mail.