To Wouter: No, I never used anything else than CVS for everything serious. Whenever I tried any of them for something (mostly because someone else used it for something I wanted to work on) they simply broke. I don't want debug my tools or use funny workarounds but get some work done on what I use the tools for. Using anything not in a Debian stable release is hardly acceptable for me (remember, it are tools), but when then even when the testing or unstable versions are not enough for simple tasks, it's just too bleeding edge for me.

"only suggests you haven't seen many large projects in the heat of code change"

That's simply a matter of style. If a checkin means a full compile, manually reading the diff and a minimal checking for correctness, writing Changelog entries and possibly adopting the documentation there is simply no need to handle checkins with a sub-minute resulution.

"Far too often have I seen people afraid to reorganize their code because that would lose history on the files."

That's a major problem, but the problem is the fear. No rcs will ever be able to track history for even most common possible reorganisations of code. Limiting yourself to what your rcs can cope with is the main problem, the abilities of your rcs are a minor one.

"How about the fact that upstream CVS development is rather extremely dead, [...]"

I prefer tools being able to do what I need over tools that will be able to adopt my needs normaly. Active development means when I encounter a bug I either have to wait a year until it does no longer bother me, or wait a week and update software on every computer I want to use on, possibly localy in my user account if I do no administrate the computer or the behaviour changes so much other usages are broken. Leading to problems to live within my disk quota and so on.

Don't understand me wrong, I'm not against SVN. I guess now (several years after everyone was already told to not use that old fashioned CVS, but not SVN version N but version N+1, because N was too brokenr; for several versions of N) it is quite useable. And things like atomic commits might even make it favoruable over CVS for larger projects. But not every project can be within the top ten list of size, coding and commit styles differ. But I believe for many people, the ratio of advantages to disadvantages still points into another direction.

The latest buzzword acronym, AJAX, is getting on my nerves. Javascript is not cool. It's an annoying, slow language. If you have ever written code in Python or Ruby or Lua, you'll agree that the syntax and library sucks. Usually I'm annoyed by the long loading times of Ajax, so please use it only where it's absoultely necessary. I agree that google maps is cool, because the alternatives would have been an even slower pure html version, an annoying flash which doesn't work properly (say hello to 'new' yahoo maps) or a very slowly starting java applet. I watched the Ruby on Rails and TurboGears intro screencasts today, because I wanted to find out how these frameworks are like to work with. The part I liked least was then in the turbogears screencast they did that pointless ajax thingy, writing javascript code and such... I liked the template engine of turbogears, python "kid". Thats a really nice XMLish template language. Read: proper XML, XHTML. Ruby on Rails templates had this ancient eperl feeling to me. Also kind of PHP like, but not as worse. In contrast to PHP you can actually parse it. Still, you can't properly validate your XHTML template files. So I'll probably try out TurboGear sometime soon, and if I'm not happy with it maybe Ruby on Rails next. I'm very happy to see these new frameworks for free languages. I heard a lot about Java Frameworks recently, but they all seemed so overengineered, and then there is this Java annoyance... A python or ruby solution is much nicer there.

I never thought anyone would still seriously advocate CVS over anything else these days, but I was wrong. Bernhard:

• Ever heard of atomic commits? You modify three files, commit. Turns out that in the time between you starting to edit stuff and you committing, someone else changed some stuff, and your commit doesn't apply somehow. The first file is committed, the second breaks, and the third isn't committed. Congratulations, you just broke the build, and you'll have to manually fix it. When editing three files, that's manageable; when your commit is (say) about 15 files or so, it's not really as manageable anymore. CVS doesn't have atomic commits.
• About it being rock solid, I only say Hah. I've seen way too many cvs pserver bugs out there—and that's still the only possible way to go if you want anonymous CVS access.
• How about the fact that upstream CVS development is rather extremely dead, after most of their developers started to develop subversion because the CVS code is so extremely horrible to maintain?
• Moving files around isn't just a nice thing to have; it's an extremely important feature. Far too often have I seen people afraid to reorganize their code because that would lose history on the files. If you can't move files, you can hardly ever reorganize code, which means that you let your version control system dictate how you should work—which is bad, very bad.
• And finally, being able to tell someone that this is fixed in r132 rather than having to say this is fixed in r1.74 of foo/bar, r1.34 of foo/baz, and r1.82 of foo/quux is very helpful. Your suggestion about dates (there's normally at least a quarter of an hour between commits) only suggests that you haven't seen many large projects in the heat of code changes. And even if that weren't true, the fact that it normally isn't a problem makes it even more of a problem on the occasions that it, in fact, does take less than a few seconds between my commit and yours

Really. Have you tried comparing CVS to anything else, on a serious project? There should really be a way for all those version control systems to talk to eachother. After all, they all have one thing in common: they're all ways to exchange patches. Surely there must be some way to device a protocol or something so that those patches can be easily sent from one version control system to the other and back again?

The stressful situation I am going through, one day before my talk at Debconf-es II can be described as:

* SAPFU - Surpasses All Previous Fuck Ups
* SNAFU - Situation Normal: All Fucked Up
* SUSFU - Situation Unchanged, Still Fucked Up
* FUMTU - Fucked Up More Than Usual
* FUBB - Fucked Up Beyond Belief
* TARFU - Things Are Really Fucked Up
* TOFU - Things Ordinary: Fucked Up
* GFU - General Fuck Up
* SAMFU - Self Adjusting Military Fuck Up
* TUIFU - The Ultimate In Fuck Ups
* IHTFP - I Hate This Fucking Place
* DILLIGAF/DILLIGAS - Do I Look Like I Give A Fuck/Shit?

Thanks to h01ger for the pointer to the wikipedia entry that describes what my work situation turned into this Tuesday (the 13th).

While I bang head on my keyboard, I have been heard to mutter "Morons... I am sourounded by morons".

Ah, Novell have released an initial report comparing the DBus and CORBA ports of EDS. As the author of the DBus port, I should make some observations. The incorrect reporting of large numbers of contacts in a book view is very odd, and I've not seen that before. I'll try and replicate that locally, I did change some message limits so maybe they are being hit. Occassional dbus_g_proxy_cancel_call assertions are known to happen. I've a potential fix locally, but it requires a patch to DBus, which hasn't been committed yet. Now to the benchmarks. The primary optimisation target for my work has been in the book views, as these are the primary bottleneck in a real-world application. This is visible in Test 1, where the DBus port takes 17 seconds compared to 72 seconds for CORBA. A number of the optimisations I've made can be applied directly to the CORBA code too, and are currently sitting in Bugzilla. Test 2, calling e_book_get_contacts() is interesting. It may be that verbose mode is enabled in DBus, which has a serious performance impact on large messages (and this is a very large message). Alternatively this difference may simply be due the message bus, which adds a layer of IPC (and thus string copies) which CORBA doesn't have. As very few real-world applications (I'd say none) use this function (it blocks the interface unlike book views which are asynchronous), this isn't a very meaningful benchmark in the scheme of things. For the calendar, there has been no performance turning done at all. It's known that the calendar port to DBus isn't quite complete, and needs cleaning up and performance work.

The GNOME team has been sitting on top of ready-to-go GNOME 2.12 for way too many weeks now, but unfortunately a series of planned and unplanned transitions affecting unstable prevented us from moving them from experimental to unstable. Today's good news is that these transitions are either going well (C++) or not at all (freetype upstream), so the release team gave us green light to start a fun GNOME 2.10 2.12 transition. There are a few aspects in this cycle that makes it a bit special and a bit more complex. GNOME 2.12 in experimental uses dbus 0.50, which is API/bus incompatible with the previous version in testing/unstable, so when we upload GNOME 2.12, the new dbus will go in too. As KDE is also using dbus in a few places, KDE and GNOME uploads will need to happen at the same time. To make it even better, dbus 0.50 has been obsoleted by 0.60, which is again API and bus incompatible with the previous version. The GNOME and KDE teams have agreed on the following plan:

1. The Project Utopia people have uploaded dbus 0.60 to experimental, and is currently waiting in NEW.
2. The mighty seb128 will upload GTK+ 2.8 and Pango 1.10 to unstable RSN, so our first version of GTK using Cairo starts to get broadly tested in architectures other than i386 and powerpc.
3. Once dbus 0.60 is accepted in the archive, the GNOME team will rush to recompile GNOME 2.12.2 against this new dbus, and test that everything is ok with the new version.
   At the same time, the KDE camp will upload their shiny KDE 3.5 debs, compiled too against dbus 0.60, to experimental, for the first time.
4. When everything has transitioned to dbus 0.60 in experimental, GNOME and KDE will be uploaded to unstable.
5. Vorlon will take a deep breath and will try to figure out how to get the two monsters in testing at the same time. Vorlon, we love you. :)

This looks like it'll take months to do, but I really don't think it'll be the case. We hope to be ready for a full GNOME 2.12 upload to unstable, at long last, pretty soon. As always, the brave can still use GNOME 2.12 in experimental with the usual aptitude -t experimental install gnome-desktop-environment. More updates as stuff happens!

Yes, you can surely tell I am no guru when it comes to describing sounds - maybe that's because in Spanish every letter has one, or at most two, sounds? Anyway, Christian, that's the way to say it - The O sometimes sounds a little bit U-ish, in some places you could see this same sound (coming from N huatl, Mexico's main indigenous language) as huaks. The k (in the x) is usually pronounced, but quite soft - sometimes we just refer to the place as "Oastepec", and nobody gets hurt (or worse, sent to Oaxaca (Huajaka - yes, the X is the only letter whose sound truly changes (and that is because Spaniards used it as a wildcard for S, KS, SH, J - In fact, M xico is pronounced M jico, but never (EVER) spelt that way besides what other Spanish speakers say. The original sound, though, was closer to M shico)))
And, yes, I am also one of many thousands of people longing to ride through the Copper Canyon. It's supposed to be really, really beautiful. Too bad Chihuahua is ~20 hours away from Mexico City :(
And about Oaxtepec's location: It's 60km south of Mexico City, not of Downtown Mexico (that would still be out of the city, but not by that much). The best route is not straight, so from my house (in South-Western Mexico City, ~15m away from where the Cuernavaca highway begins) it's about 90 minutes. The highway is _very_ good and safe, don't worry. I do expect people coming by car from the USA. Here you have a good map of Morelos state. Oaxtepec is on the third column, second row, near Cuautla. Just for completeness sake, just North of Morelos you have Distrito Federal, where Mexico City (partly) lies. The airport, where most of you will arrive is again in the second row, third column (hmmm... A pattern starts to emerge! Lets see what that means...) - We are working so we don't have to explain to you all how to get from there to Oaxtepec, I hope we can provide buses covering the route, at least in the days with most arrivals.

I currently use Google Reader to read most of the blogs I track. It seems to work in a way I like. However I'd like to be able to aggregate in Livejournal using my OpenID so I can read friends-locked posts. I don't think it's appropriate to use a public service like Google or Bloglines for this, which means running something myself. I've had a look around but not found anything that's close to Google Reader. I like just having all the posts in chronological order, not listed under each source feed. Most things I could find give you a sidebar of a tree for each feed and then you have to look at each feed in turn. I just want my content splurged at me goddamit! Planet does this, but I also want content I've read to go away by default, which Planet doesn't handle (being a generator of a static web page). So, any suggestions? I'm using Firefox under Linux, but I'm not tied to an in browser solution (I've a feeling it would be easier to get my OpenID stuff working that way though). So far I've tried Sage and Wizz. I've also looked at Straw but not installed it as it looks a little unmaintained. Liferea looks like it could be an option, so I think I'll go play with that for the moment.

Gunnar, thanks for the pictures of the Oaxtepec place. Which triggers me one question: how are we supposed to *pronounce* the place's name? The "x" is kinda puzzling in names coming from the local languages in Mexico. Having a map of the combined Mexico/Oaxtepec area handy somewhere would also help to prepare local sightseeing in the neighbourhood. Up to now, I just know that Oaxtepec is somewhat 60kms south of downtown Mexico (which makes it in the suburbs according to the giant size of the city). And, Gunnar, don't worry: I *still* plan to come back in Mexico next summer with my family. Probably not the best season, but the "kids", if I still can call them kids, have school in May, so coming at that moment is not an option. Only too bad that I really can't come a few days before Debconf and enjoy the El Pacifico train from Los Mochis to Chihuahua, which I planned to ride. To people coming to Debconf AND who have time: DO IT. The Copper Canyon train ride is for sure one of the things you have to see in Mexico. Then come back from Chihuahua to Mexico with a bus ride (a cheap bus, just like the local people do), eventually stopping for one day in Guadalajara. I bet you will then appreciate this small bit of real mexican life.

As it seems people are arguing about the revision systems hype, I just wanted to point that CVS rulez. Sure, it does not $some_obscure_witty_feature but, hey, is this feature really useful? I've been using CVS for ten years, coded around 500k source line of code and honestly, it suits all my needs. To tell the truth, I don't even use all of its capabilities. So, CVS can't keep history of a file when you move it. Big deal? After all, renaming a file is just like creating a brand new one. Leave a commit message stating previous name of foo is bar if you really need history and that is it. So far, I never stumbled upon a case where this "feature" limited me or made me loose more than 15 seconds. Same for distributed RCS. Sure, on the paper they look good. Call me a moron but I never managed to use one properly. Even a large but well managed project does not need such monstruosity. Matthew is right on one point: RCS are like languages, geeks advocate languages because of a specific subset of features. But they don't realize 90% of functionality of a language is present in all other languages and the 10 other percents can be achieved with method if you really need them. I personally find very discouraging to learn a brand new RCS for every project I contribute to if upstream has decided this one is cool. If you want users to contribute, use a standard RCS as well as a standard mailing-list system, common language, etc.

I'm very sad how things went with Thomas NM application. And I know that I have done some things wrong, but I had a hard time in work and real life in the last time which left me back with to less time for debian stuff, especially NM stuff. I told that to my NMs and I hadn't a clue that Thomas was thinking like that. If I had a clue that Thomas wants to step back from his application I would tried to find the time to write his report sooner. It was sheduled before christmas by me, but now its too late. This could all be prevented if I had be informed by his step before.

But what is really sad is that there are some people complaining in their blogs, again without talking to me before, that don't really know whats happened, telling people wrong or half true things. And even if they got a mail from me they don't have the integrity to answer the mail or take things right in their blog. Thats even more sad than the whole thing.


Thomas: As I told you I'm still interested in getting you into Debian, so I won't remove you from the queue in the next time. If you are interested I can also give you a phone call and we can talk about that things.

Josselin Mouette has thrown down the gauntlet -- Subversion is the One True Revision Control System and we should all just Stop Worrying and Learn To Love The Handcuffs. In particular:

[...] just use subversion, and if you feel it's missing features, please contribute them. By standardizing on subversion, we lower the barrier for people wanting to contribute, instead of increasing it by asking them to install and understand new tools.

Quick thought experiment, Josselin: replace "subversion" with "Java". Or "Perl", or "C", or even "Python" or "Ruby". Or any other language. It doesn't matter which one. Even if the language you substitute is a good one, and one you happen to like, it's still a fairly obviously braindead idea -- that there can possibly be One True Programming Language for all problems, and that there can never be any improvement that can't be bolted into the existing OTPL. Revision control isn't so much different from programming languages. Different systems will provide different advantages and disadvantages. There's also incremental and revolutionary improvement that will take place over time -- machine code to symbolic to procedural to object oriented -- that can never take place within the established framework. I happen to really like the distributed model -- it reduces (though, naturally, cannot eliminate) the division between the Blessed and the Peons in a project (those with direct commit access vs. the rest of us). You can get disconnected operation for (almost) free. Also, despite the assertions contained in your article, the "barrier to entry", ironically, is actually lower with a good distributed RCS than with Subversion. The barrier isn't what you think, though -- sure, using an unfamiliar RCS is troublesome, but it's a lot less hassle than learning a new language, and people do that on occasion to hack on a particularly interesting problem. The real barrier to entry is forcing anyone who isn't blessed with direct access to The One And Only Repository to use inferior development support tools. "An example!" I hear you cry. Gladly. This morning (literally) I got enough of a handle on the internals of Ruby on Rails to actually track down a bug that was irritating the crap out of me. Being a good developer, I wanted to use revision control to track my changes. In the All Subversion, All The Time "utopia", that would involve getting an anonymous checkout, making a copy, hacking on the copy, then (when all was done) running diff -urN between the original and the copy, and sending it all upstream with a manually-created log message (assuming I could remember everything I'd done). You also need to manually remember (or encode it in your directory or something) the source of your tree, so upstream can merge it reliably (and compare it against other equivalent work that may have been done in the meantime). Doing it better, I could do an anonymous checkout, and then import it all into a new Subversion repository (or directory) of my very own, and hack on it in there. Benefit: revision control of my changes. But it's non-trivial to create a new repo and import everything into it, and there's still no automatic record made of the upstream source of my new repo. Wanting to make a second change is even worse -- I either have to make a whole new copy of my source tree (disk is cheap, but this is getting silly) or just keep forging ahead with changing my existing tree -- so this second set of changes can end up being dependent on the first (which is Not So Great if upstream don't merge your first patch). In the "new repo" scenario, you can branch from the root of your new repo and continue hacking on your newly created branch, which is a good start, but it's still icky. And good luck having the system track new commits from upstream while you're working, too. If the project was using a DRCS, in contrast, the problem would reduce to making a branch into your local archive, hacking (committing at will), updating with new upstream commits as you go along, and then publishing your changes to a public place for reintegration (or, in some cases, sending your changeset via e-mail). Oh, and before anyone starts screaming "if anyone can branch, it will encourage forking!", consider which is more likely to result in a permanent fork (rather than a temporary independent line of development): a local set of changes in a tarball or local subversion repo, both of which are hard for anyone else to collaborate on without major pain; or a branch in a simple-to-publish (or push) designed-to-be-shared DRCS archive, which automatically keeps all of your interesting metadata intact and coherent across archives, merges, time, and space (and possibly even dimensions). This utopia doesn't really exist, and is hampered by everybody having their own Pet DRCS, but the problem, I'm fairly sure, is transient, and my main point isn't even so much against the choice of Final Ultimate Solution, or even the problem space, but more about the attitude that everyone should get behind Any One System and stay there. I can't imagine the world of pain we'd be in if Josselin had posted his message a few years ago (but with s/subversion/CVS/i, naturally) and everyone had followed his advice -- can you imagine per-file changesets with no effective merge capability for the rest of eternity? <shudder />

The past few days I have been accumulating knowledge. I have encountered quite some new concepts and stuff they use here, but also old knowledge had to be refreshed. I have looked again at XML technologies as W3c XML Schema, RelaxNG, XSLT and XML in general. I had to dive into OCaml since that’s the main language used here. Fortunately I can make use of my past Haskell experience there. So now I have yet a new language to add to my used-programming-languages list. I have used my webspace provided by MACS to set up a page about all my internship work related stuff. It gave me another opportunity to make use of webgen again, what a great tool! Simple text files in a directory structure are converted to a site with such ease. A title, menu and navigation bar, all done automatically and it’s all static HTML in a nice XHTML 1.1 compliant package. MathLang I have read all the available presentations and papers on MathLang that I could find. At the TU/e I was taught the Weak-Type Theory by professor Nederpelt (which is a basis for this mathematical language), so I have some background in this area. I’ve tried to write a page about what MathLang is. I’ll probably have to improve the descriptions and make the whole thing clearer. The Plan My first task will be to write a MathLang-Core concrete syntax compiler that can generate the still to be defined XML format. The AST used in this compiling process should also be prepared so that the MathLang type checker can run on it. Once the compiling to XML is done, I might be able to use XSLT to transform it back to the original syntax, hence proving the equivalence of the two syntaxes. For monitoring my progress, see my online log.

In light of criticisms I would like to confirm that of the twenty-eight months I was in NM, many months were spent by me answering questions. I didn't mean to leave the impression that I have been waiting for actions by Debian for that whole time. In fact I have only been waiting seven months for the latest step, for example. These criticisms have made me realize that what I was seeing as bureaucracy was really just sublimated awareness of my own failings, projected onto a system that any objective observer would agree is fulfilling its mission. I just have to admit not everyone has the right stuff for this job. The title 'Debian Developer' has to stand for something. Something strong. And it's the job of the New Maintainer process to keep Debian strong. Of course this means that some people won't make it. But dammit, Debian is just too important.

As it looks like blogging is now the preferred way of sharing your thoughts, I guess I'll have to answer in my own blog to the problems starting with Thomas Hood post about withdrawing from the NM process.

Some people have replied to this and I think I should present my position, as I'm the most active of the unresponsive NM Front Desk, yaddayaddayadda.

Until Thomas blogged, I did not know that he considered the missing report as an issue.

To clear up the situation: Thomas completed all stages of the AM checks after he was reassigned to Alexander (formorer) this spring.
When Alex wanted to prepare the reported, he noted that some mails from the conversation between Madkiss (the old AM) and Thomas were missing. No problem, FD to the rescue, I still had those mails in my archive. After these initial problems, Alex' daytime job needed a lot of attention, so he didn't write the application report. I kicked him on a regular basis to do so, but it needs time and is not really very interesting, so it got delayed.

OK, that delay is not a good thing, but Alex told me that he planned to do the report on Saturday. Yes, this delay is quite annoying if you worked so hard and always had to wait for your AM to check your stuff and blabla. Now, the problem I have is that in this case, it's simply not true. Madkiss was assigned as AM to Thomas for 18 months - of these 18 months, 15 were spent waiting on a reply from Thomas to the usual NM questions.

Thomas, I can understand if you don't like the templates and think that they're boring, useless and whatever. But don't blame other people for time you have lost.

I seriously tried to persuade Thomas Hood to revoke his withdrawal from NM, but he made it official now. According to him, both his current (formorer aka Alexander Wirt) and his former AM seem to have lost the AM correspondence with him. So we just lost another NM due to Debian’s bureaucracy. Normally he should have contacted the Front Desk to just get a new AM, but this already was his second.

Just reading the comments associated with a post from the reddit.com people about a rewrite of their entire site from Common Lisp to Python. The Lispers are screaming "noooooo!", the Pythonistas are grinning smugly, and the Rubyolas are asking "why not us?". In the middle of it all, comes this gem (unfortunately, posted by "Anonymous", so no attribution):

Real men would design a custom ASIC and write a new FORTH system optimized for Reddit, complete with custom developent environment, web server, etc. It would multiply the development time-to-1.0 by about 2-4x, but the entire system would be smaller than the ethernet plug, would handle a saturated gigabit pipe with sub centisecond latency, never crash, and use less power than your toaster. Everyone would be too busy saying "WTF is FORTH?" to bitch about you not using Ruby on Rails. Then you'd lose to the guy who did it in PHP (*turn* *puke*), because it's not about the technology, stupid.

This is the new hype of last years. No development can take place with these so cool tools. Crap, I just maintain the bloody localization for apt and dpkg and, as the developers of these packages use distributed revision control systems, I'm forced to use them as well. I have never lost so much time in fixing broken stuff in my archives. OK, I'm a moron certainly but I use RCS things for several years right now (the old CVS/SVN and the like with a centralized repository) and I HAVE NEVER LOST SO MUCH TIME since I use tla, than bazaar. More fun: it seems that baz is getting obsoleted by bzr right now as obviously geeks cannot live more than one year with the same tool. So I will have to convert my archives if I want to continue helping in apt/dpkg localization. Of course, I know that people will help morons like me to do it, but, hey, this will AGAIN be lost time. Thanksfully, the D-I developers are wise people and we don't use distributed RCS but a good old solid SVN for 3 years now. Frans, Joey, don't ever think about changing this, please.... So now, I'm left with a change that I can't commit in my local archive for a French man page of dpkg, as suddenly for no reason, the bloody baz complains:

A/  arch /dpkg/dpkg--devel/dpkg--devel--1.13/philippe.batailler@free.fr--2005
A/
 arch /dpkg/dpkg--devel/dpkg--devel--1.13/philippe.batailler@free.fr--2005/patch-log
A
 arch /dpkg/dpkg--devel/dpkg--devel--1.13/philippe.batailler@free.fr--2005/patch-log/patch-1
M  man/fr/dpkg.1
M  debian/changelog
M  ChangeLog
arch_commit: unable to acquire revision lock (could not rename file.)
tree: /home/bubulle/src/debian/dpkg/dpkg-1.13
revision: bubulle@debian.org--2005/dpkg--devel--1.13--patch-88
url: /home/bubulle/arch/bubulle@debian.org--2005

So nice: I'll again waste precious time asking on IRC for help and hearing people telling me to switch to <insert your favorite RCS system here>. This will be a so wonderful Sunday....