Yesterday was Akshaya Trtiya (Akkha Trij in Gujarati.) It is notable for being auspicious all day long, one of only 4 days in the year when you don't have to look at the muhurta. I did Lakshmi puja (kanakadhara stotra patha) and began several new projects which I will blog about soon. But the real reason boys and girls love Akshaya Trtiya is it is the day when Akshaya Trtiya Akshaya brings presents to all the good children. This year I got Feisty Fawn from Kubuntu, a six-in-one games set for drinking about 20 gallons of Coke Zero courtesy of mycokerewards.com, and some Philip K. Dick books for winning a caption contest on a blog. All is not well. There are some atheist secularist communists who claim that Akshaya Trtiya Akshaya doesn't exist and people should refer to the day as "Thursday." Well boo to you I say. Boooooooooo!

As some people may know, there's a group of us getting some official Debian Tartan (thanks to Phil at hands.com) kits made up for DebConf 7.
Moray got back from the weavers today, with a nice photo of the tartan being weaved :)

Erich Fromm, 1900 - 1980, internationally renowned Jewish-German-American social psychologist, psychoanalyst, and humanistic philosopher. Fromm describes three ways in which we escape from freedom: 1. Authoritarianism. We seek to avoid freedom by fusing ourselves with others, by becoming a part of an authoritarian system. There are two ways to approach this. One is to submit to the power of others, becoming passive and compliant. The other is to become an authority yourself, a person who applies structure to others. Either way, you escape your separate identity. Fromm referred to the extreme version of authoritarianism as masochism and sadism. Authoritarians respond to a painful existence by, in a sense, eliminating themselves: If there is no me, how can anything hurt me? 2. Destructiveness. Others respond to pain by striking out against the world: If I destroy the world, how can it hurt me? If a person’s desire to destroy is blocked by circumstances, he or she may redirect it inward. The most obvious kind of self-destructiveness is, of course, suicide. But we can also include many illnesses, drug addiction, alcoholism, even the joys of passive entertainment. 3. Automaton conformity. If I look like, talk like, think like, feel like… everyone else in my society, then I disappear into the crowd, and I don’t need to acknowledge my freedom or take responsibility. It is the horizontal counterpart to authoritarianism. The person who uses automaton conformity is like a social chameleon: He takes on the coloring of his surroundings. Since he looks like a million other people, he no longer feels alone. He isn’t alone, perhaps, but he’s not himself either. The automaton conformist experiences a split between his genuine feelings and the colors he shows the world.

So, yes these three topics, the caveat, the book Better than Well and Hot Latino Bodies are related. You just have to stick with this long post to find out why… *** As I progress slowly but surely with my book manuscript, I am really coming to see how a dissertation and book are quite different creatures. I think one of the most important and noticeable differences is that a book has a lot more short caveats and warrants than necessary in a dissertation. I think there are two main reasons for this. One of which is has to do with your committee members, the primary and (usually only readers) of the dissertation. They are a lot more prepared and adept to ingest complex ideas than lets say undergraduate students, because that is what they are trained to do and because most of them are much more familiar with your topic because they have been with it nearly as long as you have. In a dissertation you are also allowed to (and often expected) to go on and on, ad naseum, with your theoretical explanations that help substantiate what are otherwise shakier, initial claims. For various reasons, for a book, especially if you are not some FFT (Famous French Theorist), you are strongly encouraged to dump most of the theory in favor of providing a streamlined version (which really, is preferable of course, but extraordinarily hard to pull off). I have been thinking a lot of the caveat because I have just finished re-reading a book Better than Well that is not only fascinating in its own right but brings the caveat to a stunning art form. The author, Carl Elliot, is a philosopher/bio-ethicist and the topic of the book, broadly speaking, examines how the rise of new enhancement technologies (prozac, plastic surgery, sex change surgery) is bound tightly with longer-standing, distinctly American ideals, such as the autonomous, self-directed and authentic self. It is one of those rare books that can be read by your father, aunt and uncle, tossed over to a willing teenager, and assigned in all sorts of college courses and still manage to impress all sort of academics in all sorts of fields. Part of the reason for his broad appeal is because the book is thoughtful and clever and so chock-full of really interesting examples that you are hooked and want more of his tasty intellectual Kool-Aid. So while he has one main focus, which largely triangulates between enhancement technologies, selfhood, and consumerism, in the process of exploring them, you learn about a bunch of other really neat topics: suburbia, the history of cosmetics and childhood, odd social phobias, long-gone and culture- bound disorders like dissociative, fugue, amputee wanabee’s, extreme blushing, and so much more. Along with crystal clear writing, he also throws in some classically funny lines, my favorite one currently being: For better or worse, suburbia has come to stand for something than can be survived only with minor tranquilizers. Another reason he manages to pull this Houdini-like feat is because of his judicious and artful use of the caveat, which is really the only way he can bring forth complex ideas, in a fashion that is much more accessible than is usually done in a purely academic book. To take on example, when he introduces the usefulness theories of Thorstein Veblen, an economist usually known (and only barely), by academics, he opens in the following way, because in many ways, if you just decided to pick up a copy of Veblen, his style make strike outdated:

Reading Veblen nearly a century after he wrote The Theory of the Leisure Class, it is not easy to know which parts of the book to take seriously. It comes off as equal parts intellectual theory, social satire, and crackpot polemic, (and goes on for a full more paragraph) and then says Where Veblen is prescient, however, is his sense that in a consumption economy, consumer goods would become markers of who we are. p. 103

In this way he can say, ok Veblen is useful because of this specific reason” and yet communicate to his academic readers that he knows the limits of Veblen. No matter how much I love the book, and now matter how I think his use of the caveat is stunning, there are two problems I have with it. In one case, I think he fails to give one of the most important caveats. He paints a picture in which all of American society is ensnared in dominant social codes and mores (which somehow all point back to consumerism and capitalism and a desire to improve the self). While there are points he seems to back away from that sort of statement, and a few rare points where he ascribes his insights to the group I think he should mainly be sticking to white, liberal-leaning middle-class Americans I think there are more instances where he paints a picture of America as far more uniform than it actually is. According to his account, no one is immune to the forces he so eloquently writes of and so in the end the environmentalist activist, is as caught up in the traps of consumer life-style as is the investment banker on Wall Street. It lead hims to say such statements as

Many Americans today learn who they want to be by listening to a Methodist minister or a civics teacher but by watching advertisements for The Gap.

Ok while he bit about the civics teacher may be true, any consideration of lets, say… the religious right in this country, which, as we know from recent elections, don’t represent a teeny-tiny itsy-bitsy minority (and for a fascinating glimpse into the world, I would recommend Jesus Camp), would bring holes, and sizable ones, to that sort of statement. Many Americans do in fact listen to their minster. And this does not only help explain the deep divisions in this country, but I bet because they do listen to their pastors, their notions of the good, the self, etc, are going to be pretty distinct from those he describes (and gain see Jesus Camp to get at this point) It is not that the religious right exists outside of the web of consumerism we are all at least partially caught in, and indeed, a lot of the new Protestant religious movements here and elsewhere as Jean and John’s Comaroff’s work has shown can be all about securing a more robust middle class lifestyle. But we must remember that even something as powerful as consumer capitalism or dominant ideals of an authentic, beautiful self though powerful and more often than not work in concert with each other do not quite have the power to efface all meaningful difference between lets say a white, liberal middle class woman and let’s say, many Latinos, who, do, let’s not forget, comprise a huge portion of America. Many Americans have a very different picture of the ideal female body than the picture he explores, which is skinny and lanky and forever youthful (and hence the appeal of botox and lipo). Let me provide just one example drawn from the annual Puerto Rican day parade and this hold true for the one held either in NYC or Chicago. Along with a blizzard of Puerto Rican flags, what you may also notice is the abundance of really bright spandex being donned on ladies that are not by any standard of the word slim. I am sure that any middle class lady (you know, the type who spends 5 days of the week working out at the gym, wishing her thighs were just a little thinner), would feel morally repulsed in seeing that sort of image, that is if they even bothered to go to the parade. But among many Puerto Rican men (not all) a sexylicious and extra-curvy, meaty Puerto Rican woman, decked out in tight & bright spandex, will like bring on a loud HAY MAMITA, ven ac ”………………… which roughly translates into You are HOT… Like I want you NOW. (more…)

So, this is my last evening (and when I remember correctly the first one I’m at home) of my holidays. All began last Friday called “Karfreitag”, a national holiday. To be correct, the first party was already on Thursday and they continued daily till Monday evening. The best event in this time was Sunday afternoon, some minutes after I waked up Debian GNU/Linux 4.0 aka Etch was released, what a feeling. It was especially interesting because it’s the first stable release with some of my packages and it was a great experience to see how releasing and planning works. I often think back to the two bug squashing parties in Zurich, one in September and one in October iirc. Back to my holidays: First it was planned that I go with my sister to Zurich from Monday evening till Thursday evening, but then I got a appalling call from madduck who told me that he is in the hospital in Zurich with several broken bones. We planned to sleep in madducks flat and so we couldn’t get the key and went Tuesday morning. Walking through Zurich, getting some informational material from the University Zurich for my Sister (she maybe wants to study there) and the visiting madduck. After the visit we went again to the center of the city and walked without a real destination. In the evening we finally went to Oerlikon and went to “our” flat. After installing our sleep places (goddamn, I want to have a waterbed) we went to Migros to buy some food and drinks for the evening and the next day. The next day we really got up quite early and visited Zurich with a city guide, a lot of sightseeing and hanging in some bars. In the afternoon Daniel Baumann also was in Zurich and we went to have a drink together and also Tobias Ast came and staid with us till the next evening. We really had fun together and the main thing we did on Thursday was relaxing on the lake of Zurich and in the evening we went home. Then it was finally friday, I looked forward to this day for about one week, why? The release party in Zurich!! It was my first release party on the Irchel area in Zurich, we grilled, had some beer together and talked about god and the world. It also was the first time i met Adrian von Bidder and Mathias St rmer in person, especially with Adrian i had a longer interesting discussion about network devices from Cisco and their special prices. Saturday was already the next party day. When I was 13 we had a supply teacher for our sick teacher for 2 months, I was her horror pupil. Fine - some weeks ago I met her again in a Pub in the evening and we staid together the whole evening and became good friends in a way, so I was also invited (as the only of her pupils) to her flat share party. I met several “new” people and some of them (mostly IT students) recognized my Debian t-shirt and I had some interesting discussions about free software and had to explain the philosophy of Debian to some of them. So yes, now it’s sunday, I’m more tired than before my holidays but I’m really happy, my holidays were great because of some adventures. Regards to all to my friends… Tomorrow I will continue working and have several tasks open, especially upgrading some Debian servers from Sarge to Etch (Spamfilters, LDAP, Proxy servers…) and I hope I won’t have many troubles. In addition I have also some tasks open for Debian which I’d like to complete this week.

After recent posts to debian-i18n about release notes translations and the few blog posts about them, I quickly looked at the Debian Doc Project CVS just to check the status of the French translation of this document. Indeed, the last update by Fred Bothamy was commited 1h15 after the last update of the corresponding English version. Fred has been able to keep up with the crazy number of updates during the last days. Bravo, Fr d ric, tu es un brave parmi les braves. The same congratulation set goes to Philippe Batailler who maintains the French translation of the Debian Installation Manual for about 3 years now (I suspect this to be much much more ancient but the D-I SVN log only goes back to September 2003, when the manual was converted to DocBook XML.

Yesterday night, Elisabeth planned a surprise for me (birthday time) and had tickets for the concert of Gotan Project at Le Grand Rex, Paris. It was indeed the fFirst time I ever went in that concert hall, which is indeed a huge old-style movie theater with comfortable seats, room for legs, nice art-deco decoration. Great after a normal work day..:-) The music of Gotan Project is a nice and elegant mix of electronic music and argentinian tango influence, featuring French, Swiss, Argentinian and Franco-Argentinian artists. Something I enjoy since it was started by Philippe Cohen-Solal a few years ago. The "band" made it well for a music that is mostly a studio music. Ten arsists on stage and the proeminent and warn voice of Cristina Villalonga. The artists were "home" mostly as the band born very close to the Grands Boulevards and, therefore, the atmosphere was friendly, with artists clearly being happy to be there. And, as a surprise, the closure featured Saian Supa Crew as guest artists for a great mix of French rap and the GP electrotango. Overall amazing experience and I hope this won't be the one and only concert we attend for 2007. After all, Peter Gabriel should be touring over Europe and I always try not missing his concerts since 1977. For those interested, the Lunatico tour dates for Gotan Project are available here.

John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven't yet converted the primary SCM repository for e2fsprogs to use git (yet), I've reached an opposite concolusion from John, and yet, I can't really argue with his observations.

The main reason why I've come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has "more legs" than hg, and with the release of git 1.5.0, it became clear that the git community was willing to work on these particular shortcomings, which is why I started working on it and making plans to migrate e2fsprogs to use git. The main reasons why I think git is more powerful is that not just that it supports lightweight branches inside a single repository (although I really do like that a lot since it makes it a lot easier to run multiple experiments in parallel and switch back and forth between them), but also because git is much more Unix-like; there are lots of tools that enable scripting for either new git extensions or for ad-hoc shell pipelines that you can't really easily do in hg without breaking into Python.

But git definitely does have shortcomings, and John is on the mark with most of them. Git's documentation is very poor. Part of the problem stems for tutorials that were written to work with older versions of git (don't try using anything older than git 1.5 if you are a git newbie; git 1.4.x is far more user-hostile) or were written for use with systems built on top of git 1.4.x, such as Cogito. (I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git.) The tutorials that are distributed with git 1.5 are much better, but they clear do need more work.

It is true that the many of the man pages in git are lacking, and John's criticism of the fact that many man pages do not list all of the options that they take, but rather refer to other man pages is on point and accurate. It has gotten better (take a look at the git-diff man page from the git 1.4.x days, and laugh or cry, depending on your point of view) but there is still much work to be done. In practice, the better way to use the git man pages is to skip past the options section, and take a look at the Examples section. This shows a number of ways that a particular command might be used, just as a Unix master might say, "Grasshoper, see how you can use awk to do all of these amazing things."

I do take issue with John's assertion that git's philosophy has been to make life easy for the central maintainer, and not to pay much attention to the needs of individual contributors. That may have been Linus's development priorities but with Junio having taking over maintenance, there have been a lot of improvements in git 1.5.0 to make life easier for people who are tracking remote repositories and making changes, in particular the git remote command.

The most interesting observation which John made was the non-intuitive semantics of git-format-patches, and I did find it interesting that one commenter posted a solution which made perfect sense given other git commands, and yet didn't work. Obviously the person who posted the comment didn't bother to try it first, probably because in most other places git is actually pretty consistent; but git-format-patch is one of the places where most painfully is not. I view this as a bug that should be fixed, and fortunately I think it can be fixed without breaking the git-format-patches is currently being used. (The problem is that it doesn't use the standard notation so it is more convenient in the common case of how it is normally used, where the end point is not specified and is always the the tip of the current branch. I believe we can avoid the UI surprise by making git-format-patch use the standard revision range parsing if parameter contains the ".." or "..." operators. I'll have to try to prepare a patch which does this and see whether it gets accepted.)

So basically git does have short-comings, yes, but people will come out in different places about which tools is best for them, and that's OK. Actually, I think the ultimate solution for this problem is to build a bidrectoinal hg/git gateway. There are tools that will export from hg to git, and vice versa, and they are actually pretty sophisticated. I don't think it should be that painful to create a tool that does incremental exports in both directions, maintaining state so that the right thing happens when a commit gets made on the git side, and gets exported into hg, or vice versa. Ultimately I think that's the best solution, since that way people can use whatever tool they want, and still contribute and development as first class citizens. This is the main reason why I've held off on converting e2fsprogs to git (although I have made some private test repositories which I'll use to take advantage of git's superior annotation and query/log utilities); I don't want to make a git repository of e2fsprogs public until I'm sure that a bidrectional gateway tool won't require me to make any changes that affect the commit-id's, since that would invalidate any work that people have done that was based on a clone of the coverted git repository.

I have a rough design for how to do the bidirectional gateway, but the issue is finding time to implement it. Anyone with free time looking for a project? If so, contact me. I probably should have written this up as a potential Google Summer of Code project, but it's too late for this year. Oh, well.

I've been writing a lot about this lately, I know, but it's an interesting landscape.

I had previously discarded git, but in light of git-cvsserver (which provides a plausible way for Windows people to participate), I gave it a try.

The first thing I noticed is that git documentation, in general, is really poor. Some tutorials that claim to cover git actually cover cogito. Still others use commands that are much more complex than those in the current git -- and these just the ones linked to from the git homepage.

git's manpages aren't much better. There are quite a few git commands (such as log) that take arguments that other git commands accept. Sometimes this fact is documented with a pointer to these other commands, but often not; a person is left guessing what the full range of accepted arguments are.

My complaint that git is overly complex still exists. They've made progress, but still have a serious issue here. Part is because of the docuemtnation, and part is because of the interface. I wanted to export to diffs all patches on the current branch in a repo. I asked on #git, and someone suggested using the revision specifier ..HEAD. Nope, didn't work. A few other git experts chimed in, and none could come up with the correct recipe. I finally used -500, which worked but is hackish.

git's lack of even offering support for a human to indicate renames also bothers me, though trustworthy people have assured me that it doesn't generally cause a problem in practice.

git does have nicer intra-repo branching than Mercurial does, for the moment. But the Mercurial folks are working on that anyway, and branching to new directories still works fine for me.

But in general, git's philosophy is to make things easy for the upstream maintainer, and doesn't spend much effort making things easy for contributors (except to make it mildly easier to contribute to a large project like Linux). Most of my software doesn't have a large developer community, and I want to make it as easy as possible for new developers to join in and participate. git still utterly fails on that.

I tried bzr again. It seems that every time I try it, after just a few minutes, I am repulsed. This time, I stopped when I realized that bzr doesn't support tags and has no support for emailing changesets whatsoever. As someone that has really liked darcs send (and even used tags way back with CVS!), this is alarming. The tutorial on the bzr website referenced a command "bzr help topics", which does not work.

So I'll stick with my mercurial and darcs combination for now.

I announced the first version of a hg send extension yesterday as well. I think Mercurial is very close to having a working equivalent to darcs send.

Awhile back, one of my favorite bloggers, Philip Dawdy of Furious Seasons, deviated from his usual posts that place a big fat critical magnifying glass under the marketing (and other shady) tactics of Big Pharma and wrote a very thoughtful, (also furious) account of Web 2.0 claiming:

this whole Web 2.0, social networking, virtual community business is essentially a pornography of the self a projected, fictionalized self that is then worshipped by the slightly less-perfect self.

It is a little off the top at times but makes some really good points that I agree with (and generated a really interesting discussion). It merits reading alongside Danah Boyd’s recent rumination on the very same topic, fame, narcissism and MySpace, where she seeks to address narcissism but she deflects blame the suite of technologies and places it instead on the broader set of cultural practices that sustain this accentuated inward focus:

My view is that we have trained our children to be narcissistic and that this is having all sorts of terrifying repercussions; to deal with this, we’re blaming the manifestations instead of addressing the root causes and the mythmaking that we do to maintain social hierarchies. Let’s unpack that for a moment.

These two read nicely with an older piece in Harpers Attack of the superzeroes: why Washington, Einstein, and Madonna can t compete with you . The author, Thomas de Zengotita claims “Being famous isn’t what it used to be” because new technologies of mediation and reflexivity (and by new, he means a lot more than web 2.0, it includes reality shows, focus groups, karaoke, the hyper-representation of the real stars, alongside the usual suspects) and concludes that we life as if we were always on stage, concluding somewhat disparagingly “We are all method actors now.” Of course, this is an important part of the story but not the whole story. There are times, for example, these social technologies help to patch up what is arguably as common in North America as is this narcissistic self, which is the fragmented self, that comes into being, for example because many of us, migrate here and the, for example, for work. So a social networking site like Facebook, provides somewhat of a stable point of reference, where there are individuals collected, in the same place, even though the people are no longer really in the same place. It is at least a recognition of certain relationships whose “local” face has now passed but instead of completely completely fading into the realm of memory, the past lives on, albeit in transformed ways, within a virtual space. This facet of social networking is not particularly narcissistic, but is building new technologies of memory that I think works somewhat against the conditions that fragment the self. And while the patching up of the person may make an individual “whole” and “individuated” it seems it is a form that is much more mundane than the “pornography” or “narcissism,” explored above, though of course, they do abound–but karaoke, that is always pornography of the self. But… porn can be fun.

About two weeks ago, I wrote about my thoughts on Mercurial and how I was switching to it from Darcs.

At the time, I had skipped Git because of its lack of Windows support. I have some contributors to pieces of Free Software that I write that use Windows, and that seemed a pretty big flaw.

But I recently discovered git-svn and git-svnimport, both of which look like great tools for working with our friends using svn that haven't yet gotten ahold of the DVCS light. Then I noticed that Git has a CVS server emulation tool, which means that Windows users can use TortoiseCVS to interact with it. Nice.

I spent some time today learning Git. This was a lot easier having already learned Mercurial. Git and Mercurial have very similar philosophies to a number of things, but the Mercurial documentation explains all this far better than the Git documentation does.

I'm going to have to try both of them out more and see what I think. But git-svn (which is bi-directional) certainly looks like a very nice thing.

Neither of them have something as nice as darcs send, though.

I was away in Philadelphia over the past week for the annual Drosophila meeting. My boss presented our work, and I shared a poster about it with the postdoc in the lab. I was constantly running from talk to talk and from poster to poster, trying to soak up as much as I could. I also got to meet a fair number of famous people, which was pretty awesome. It's not every day you get to meet a Nobel laureate, but that's why you go to these things. We got a lot of good feedback on our work, and we've basically gone in to overdrive to try and get the paper (which will be my first one) submitted.

Since I've been back, I haven't had any significant time to do Debian work, mainly because I've been in the lab or just taking care of life stuff almost non-stop. I managed to sneak in some time to tweak the XSF wiki pages, but the rest of the team has been handling things in my absence. I wish I could report on what they've been up to, but I haven't looked at any non-personal email for the past week.

Finally having a chance to check planet Debian today, I'm excited to see Martin's various posts about the release management for different free software projects. Obviously that's been the major thorn in our side for a while now, and while we're improving we can obviously do better. I'm looking forward to a post-mortem report and discussion from the release team about what the next steps we need to take are. I have my own ideas of course, but the release team has a much wider field of view than I've been able to achieve.

Off to see the Shins tonight, hopefully they're as good live as I've heard.

The design is now agreed with the weavers, but unfortunately I misunderstood the price-list, so the prices I've been quoting for hand-sewn 8-yard kilts, and machined lady's 4-yard kilt-skirts were too low -- the correct prices for those and a couple of other things being:

Hand-sewn, 8 yard kilt:	£420.00
Machined, 4-yard, skirt-kilt (lady's):	£237.50
Machined, 6-yard kilt:	£270.00
Waistcoat:	£113.00

I'm sorry about quoting prices without making absolutely sure they were correct, the reason was that I was quoting the prices for standard weaves from stock, and it turns out that the custom weaves are more expensive. That said, note that the machined kilts are £80.00 cheaper than the previously quoted price (for hand-sewn), and that these are perhaps more appropriate to the use to which many of us will be putting the kilts anyway (hand-sewn are really an evening dress item, after all) Even so, I'll probably still fork out for the full 8-yards, on the basis that my dinner jacket is falling to bits after 20 years wear, so I need something new anyway. In case you're wondering what on earth I'm talking about, this has been discussed elsewhere. Just to make sure there are no other nasty surprises, if you are of a more rotund nature, you may find that it will take some extra material to encompass your circumference -- as an example, a 7 yard machined gents kilt will cost an extra fiver to stitch, and an extra £25.00 for the yard of cloth, so will come in at £300.00 rather than the usual £270.00 Confused? Well, so was I --- The designer's sending me a fuller price list, which I will ensure than anyone on the list of currently interested people is fully conversant with before we put the order in, so don't panic that I'll spend your money without giving you a final chance to come to your senses ;-) I hope that doesn't result in everyone changing their minds, but I'll understand completely if it does. Alternatively, you could decide that this is an opportunity to save yourself £80.00 by opting for a machined kilt (which AIUI are still made to measure, but just have proportionately less work and material in them) Anyway I'll post any further developments here so as not to continue spamming the lists. So, if you're interested in getting hold of any of the above despite the new prices, and have not yet told me you need to mail me now! -- the order will probably go in at the end of the week.

Today I got accepted as Debian Developer. I would like to thank the following people (in random order) for their involvment in my NM, mentoring and sponsoring uploads.

Philipp Kern, Michael Schiansky, Daniel Baumann, H ctor Garc a, Norbert Tretkowski, Werner Heuser, Marc Brockschmidt, Lars Wirzenius, Christoph Berg, J rg Jaspert, James Troup, Martin Krafft (feel yourself added if I forgot you, hopefully not)

Oh and congratulations Holger.

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

• it was dead simple to make a working one
  
• the documentation is really verbose and complete
• there is a default behaviour for every ebuild, even for a minimalist ebuild
• if your ebuild has a special need, the ebuilt can override the default behaviour by redefining the function (target, in debian/rules-speech), but you don't need to, in most cases
• there are some already defined classes which can be inherited to obtain a tweaked default behaviour (imagine typical cmake build system, typical autotools build system, typical kde build system - and iirc, this can include build dependencies)
• all the information about the package is centralized in one file which is human readable from the start, plus that is obvious, or one can understand fast what a field/function/variable means from the start, without digging through the documentation continuously
  

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.

Wouter Verhelst wrote:

"That line 754 came across pretty horrible, TBH. I didn't have much time to think my reply through, and it shows. What I wanted to say is that for the bits the NMs are actually involved in (ID check, T&S, P&P, etc), P&P is what takes up the most time. Waiting for an AM, waiting for the FD to check the report, and waiting for the DAM to figure it out and say "okay" all does, indeed, take much longer than that, on average."

I still don't understand how this matches the NM statistics that show the AM processing step (which includes ID check, T&S and P&P IIRC) has a shorter median than waiting for DAM. Waiting for DAM is what often takes up most time. During the audience discussion, I was told by a 2007 DD that they spent a year waiting for DAM, just like I did back in 2002. (I also was re-tested about free software while seeing NMs with very questionable philosophies get fast-tracked past me - I don't know if those still happen.) NM is still broken, but it's somehow not a campaign topic in this year's DPL election AFAICS. Elsewhere, gustavo posted that his no-show was because he was in a car crash - I think that's a fair reason for missing the debate. I'll hop on IRC after 1400 and see if I can record his answers.

I recently wrote an article or two about distributed version control systems.

I've been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.

However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.

So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn't (or isn't very well). Also, git is complex to pick up for me, and I certainly don't want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it's had for awhile, and I couldn't find even one advantage of it over Mercurial. So off I went with Mercurial.

I quickly learned a bit of a philosophical difference from Darcs to Mercurial.

Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.

It is exactly this Darcs behavior that permits both is excellent "darcs send" feature (still unmatched in any other VCS), but also causes its hang problems.

I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.

It is easy to get started with Mercurial. The mq system -- similar to quilt or other patch-management programs -- is really quite an amazing hybrid between patch management and version control. I frankly don't see any need for other patch-management tools anymore.

Mercurial has a "patchbomb" feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.

I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I'm going to keep my personal code in Darcs for the moment because "darcs send" is still easier than "hg email", but that may change before long, depending on how my experience goes.

I'd encourage others to give Mercurial a try. The community is also very nice and helpful.

I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.

In case anyone is relying on me to point them to the funniest episodes of The Show with Zefrank, this (today’s) is one, especially if you spend any time on Friendster or that odd new generation Myspace.com (when I was young, we had a public_html directory, and we knew how to set permissions on it! I also truthfully walked nearly a mile in freezing weather and snow uphill to get to the school bus). Apparently, The Show will be done for good in just under two weeks. Who knows where all the fans will go?