This year I was again at LinuxTag, after I missed the one last year. LinuxTag in Karlsruhe was always very nice, the one two years ago in Wiesbaden somehow didn't feel that good, but this time in Berlin it was really great again.
It was a nice event. I arrived late Thursday, just so I could manage to get to the Social Event before midnight. From there we headed to the hotel and next morning the fun started :-)
There were a lot of new people I never met before: Patrick Spendrin, aka Saro Engels (according to him a name from Brave New World), one of our KDE-on-Windows hackers, Claudia Rauch, our KDE e.V. secretary/manager/employee/... (what's the correct job position ?), Alexandra Leisse, who did a great job at organizing LinuxTag for KDE, Roland Wolters aka Liquidat, and we noticed that we both had lived the previous 5 years in Jena without knowing that, Eckhart, Luca, Lydia , Simon, and of course all the usual suspects :-)
We had KDE running on Linux, Windows and Mac there, I was quite impressed to actually see that working :-)
Friday evening we were invited by Trolltech to a dinner in an Italian restaurant, which was nice, and directly located below a S-Bahn (suburban train), so had that train running all few minutes over our heads.
Saturday LinuxTag ended. I took the chance and talked with some Gnome/gtk guys, and in the end we were talking about CMake again. They are also not really happy with autotools, it would be great if they would join us with using CMake. Beside all the (mainly) KDE devs (but also e.g. VLC devs), here and there we were also talking about version control systems. git seems to be quite popular, Patrick would prefer hg, me too. Also the Gnomes are thinking about VCSs, but won't switch in the near future. Their switch to svn is not that long ago yet.
In the evening we met at a Ubuntu party with BBQ at a canal, which was very nice too.
So now I'm back and have finally catched up with email, so I have time to blog again :-)
Looking forward to Akademy to meet you again :-)
Alex
Comments
GNOME won't switch VCS in the near future?
I don't have any problems switching to a DVCS, assuming it is good enough. Not sure what near future means, but *if* a DVCS if found good enough, I plan on switching to it within a year (first one module, etc). ATM I have issues with most
DVCS systems. Btw, I am a GNOME sysadmin.
Re: GNOME won't switch VCS in the near future?
Can you go into detail which issues you see with which DVCS ?
Alex
It isn't a complete list.
It isn't a complete list. See also http://live.gnome.org/DistributedSCM. This is also just my opinion.
Perhaps a generic thing: I want to relate 'pushes' to an userid. So I know who was responsible / is accountable. Seems distributed VCS just puts the info from the client into the repository and you cannot add any extra into to it.
Git: Needs serious work on usability side. Plus I want more sysadmin love. The SVN book basically explains everything you ever might want to know (issues you might see as sysadmin, various solutions and also suggestions which is best). Also: I am not sure if it is true, but believe one command allows you to change an upstream repository. I do love the uptake, but I really worry about it being understandable (just don't 'get it'). E.g. whenever some Git user shows me something, it usually isn't a perfect demonstration ('have to look this up' / 'never done this before', use of a different command after one fails, etc). I do hope I am biased regarding usability (I know I am at least a bit), but all my efforts to learn it hasn't resulted in much (I find it sort of a drawback. I want to understand why some people find it so great, but fail to do so).
I do love the personal branches (this is possible with other DVCS as well; just like it that it was done.. shows they put thought it what is useful/needed in a DVCS environment), uptake, speed.
Bzr: New format allows for greater speedup, but speedup possibilities aren't used everywhere (can be faster, but isn't atm). Smart server has VFS layer in it, bad security wise (allows chroot, but I just don't want anything which allows for corruption). The VFS layer can also be turned off, but some functionality won't work. IIRC also has a command which could change an upstream repository. Further, server side hooks cannot reject a push. Plus side, seems all these drawbacks will be fixed soon. Mostly worried if method of working is acceptable. Oh, wonder about slow uptake and focus on non-smart servers (to allow something like sftp, sometimes you make smart server slower than it could be).
Positive side: Also working on something like the git submodules, but then more usable (IIRC elijah blogged about downsides of submodules). I like the usability, PQM, plus long term design goals are nice (e.g. partial history).
Hg: Don't hear much about it. What I've heard is that Mozilla developers often ask how something should be done using Hg. Some learning is understandable, just wonder if there might be a usability problem. Hg might have been the best choice at the time for Mozilla, I just wonder what is best today / near future, combined with mid term possibilities. From what I've heard from a sysadmin, he wouldn't mind switching to something else (however, now too much effort has gone into Hg, so won't happen for at least a year -- personally I don't think you can easily switch DVCS systems as non-DVCS ones).
Further, I hate that choosing one DVCS means annoying all other DVCS users. I'd love if other users could enjoy say 80% of the other tool (not now with git-svn, which -as I understood it- severely limits the benefits of Git).