I'm at DebConf7 now, in Edinburgh, and it is great to catch up with the great bunch of geeks that is the Debian community once more. As well as working on general stuff through DebCamp (the week leading up to DebConf proper) I'm helping out in producing the video streams running the sound desk or one of the cameras. The streams are highly recommended, and you can find them on http://streams.video.debconf.org:8000/, though for the New Zealanders reading this they do, of course, happen at seriously silly times of the day. Here is the DebConf7 schedule if you want to watch :-(. We'll get the talks up in a downloadable format as soon as we can, and I'll point people at them again then. Highlights of the conference so far have been a talk by Nick Mailer on Debian Day, which was a very nicely presented run-down on the ancient history of intellectual property laws here in the UK, and the very interactive session this evening on Maintaining Packages with Git, which had some very good tips from David Nusinow as well as a lot of support from the audience. I now better understand why Penny is so keen on "git rebase", though hopefully I would have figured that out if I worked on more shared projects. It's great to see 150-odd people in the room, many of whom had some experience with Git, and there were some very heavy users with great insight into it's strengths and weaknesses. Contrast that with DebCon5 in Helsinki where I almost felt Martin Langhoff and I were unheard when we acclaimed it, or even at LCA in 2006, where Martin did a first pass at importing X.Org into Git. Of course Git itself has come a long way from then too. Another very interesting session was Martin Krafft talking about 'netconf', which is his proposal for a replacement of the ifupdown infrastructure using a much more stateless, event driven approach. This definitely looks like a well considered design and I hope he can pull it off. I've got my own talk on Thursday, so I'll be concentrating on pulling that together for the next few days. If as many people come as have said they will (50% of the people signed up for any talk at that time) then it will be a very stuffy BoF room. The venue here in Edinburgh is great, and it's nice to have a good network connection. Everything has been running very smoothly for the participants, as far as I can see, though I know plenty of people have been working very hard to make it so, behind the scenes. Weirdly, after only a short time using IPv6 at home and at work, I am finding I miss not having it readily available IPv6. I unfortunately had to disable my tunnels because adding 350mS latency to everything makes the web very frustrating. Perhaps next year we'll be able to add IPv6 to the desired network features for DebConf8 in Mar del Plata. Good to see that in the meantime the availability of the new IPv6 nameservers for .nz has been announced in my absence though.

Conversation starting tool

1. Run ept-cache info and make sure that the popcon and debtags data sources are enabled
2. Run ept-cache search -t clean -s t- less

This will show you all packages that are not shared libraries or application data, and will show you at the top of the list those packages that you have installed and other people are very unlikely to have installed. You can use that list in case someone asks you "tell me of the cool packages that you use". If you need to improvise a talk at some Linux event, that list could very easily get you started and talking for hours.

A question that people often ask about wind power (and was asked in the comments section of my previous post) is what can be done when the wind speed decreases in an area. There are several methods that can be used to address this problem. The easiest option is to simply have wind farms spread out over a large area and interconnects that can spread the load. This greatly reduces the problems but is not a total solution. The next step is to have a series of power plants that can quickly ramp up supply to meet the demand. One good option for this is gas-fired power plants, while they aren’t ideal for the environment they are cheap to build and can react quickly to changing demand. If a gas fired plant is only used when wind speeds are low it should on average be running at a small fraction of it’s peak capacity and use little fuel. Another good option is hydro-electric power which can be turned on quickly, which doesn’t produce any CO2 emissions and is already used widely (about 10% of Australia’s electricity is provided by hydro-electric power). The ideal solution is to have every user of grid power know when the electricity is cheap (when there is a surplus of wind power) and when it’s expensive (when gas or hydro power is being used). Then non-critical services can be run when electricity is cheap. For example you could put clothes in your washing machine and program it to start the wash when electricity becomes cheap, some time during the day there will be a cheap time and the washing will get done. Once consumers know when electricity is cheap (via X10 or similar technology) they can use that information to determine when to use electricity generated from photo-voltaic cells on their roof and when to use grid power. The same technology can be used for heating and cooling of your home or office, turning off the A/C for an hour or so is only going to be a problem in the middle of summer or winter, for most of the year any heating or cooling could be done with cheap electricity. These technologies are all being developed at the moment (I once briefly worked on a system that could be used as a pre-cursor to managing home electricity use for times of cheap electricity).

Share This

went to Teviot, the main Debconf7 venue, with Megan for a while. Picked up a couple of people and then left for a night in the pub. After chatting to the barmaid, Emma, who wanted her Ubuntu laptop fixed. Looks like that is sorted now. Met Ian Jackson, who surprised me by being both younger and shorter than I expected. Met Hannah, who killed Alfie, and who wasn't pregnant. Excellent night. I also hacked on xen-tools and tracked down copyright bits for debootstrap. Now to bed, via The Hobbit. The tattoo I expect people will recognize when it comes to sauna-time. In other news - I don't have a bear but now I own sandals. TODO: Print groupie badges for people.

I’m now already 9 days in Edinburgh (started writing this at day 5 already :) ), and all of them have been days of “get up at 8h, breakfast, goto Teviot, work until 23h, go back to Hostel”, with some short breaks in Teviots Bar and for Lunch/Dinner. Sounds stressful but actually was (mostly) a lot of fun, preparing the network, setting up all the core servers together with two other admins while at the same time getting a lot of request to change various parts of our Conference Management System Pentabarf to fit some peoples need at various places. The airline managed to get me to EDI, together with a few other Debian people on Friday, 8th June, around noon, where Mark (mhy) Hymers did wait already, so I didn’t need to take a bus to get into the town. On the way to Teviot I also remembered some of the places from back when we did the Venue visit for the DC7 decision. But not many, of course one forgets a lot over the time. At least I was able to remember some food places, which is always a good sign. :) At Teviot we met with Stephen (sgran) Gran to (unsorted list) have some food, unload the car, think about the way to get our uplink to our server room, check into the hostel - and whatever else we did at that day. Next day, officially called Setup day, we started to get two cables from our server room to the place our uplink is - you can see them if you go to the left site of Teviot. (The other two got there a bit later). After that we started with the setup of the network, which is pretty nice this year. We have a lot of sponsored machines that are doing various tasks, a nice network layout involving a lot of vlans to seperate stuff and a lot of (good) crack. What, you dont want to listen to boring details? Ok, here they come: - The main machine is, again, called Homer. Connected with a 2Gbit link to our master switch. It does those little things noone needs, like firewall, local mirror, dns, nagios, routing between various nets we have here, the schedule bot, etc. - There is also a Marge, who is the central point for the whole wireless network, running chillispot to have authentication for it. - Barney is used as a storage server for the video team, having some 1.5TB (raid5) space for the video data. It has 2 additional disks, 500G each, to copy data on and get them home to a video team after the conference. - Our streaming master machine at DC7 is called Lisa, and does not more than streaming for all the local clients and sending the stream out to our streaming master somewhere in the internet which then relays it to our streaming servers kindly offered by a lot of admins all over the world. - We also have Bart and Maggie, which serve as public build boxes for the attendees, where Maggie even runs a distcc open to the whole local network. - You can add the same amount of servers to this list which all do various tasks for the video team. This stuff is all glued together by a set of managed switches building our core backbone, running a number of vlans to seperate the different network segments. Which actually works quite nicely, as even at the time some expert managed to plug a cable into the same switch twice (yay, loop) - the only affected network part was that where he was in. The rest of the conference didn’t even notice it - until all of the admins jumped out of the admin room at once, looking for that fuckup. :) Sounds like crack? Probably is, but is a nice setup all together, and it was fun to set it all up together with Mark and Stephen, the two main admins for this conference who designed most of the whole structure and are the ones that really know it. I already “volunteered” them for the next DebConf to help as admins and really hope they decide to do it. Later on during DebCamp we also had Peter (weasel) Palfrader joining the local admin team. His main work here is related to the video team by hosting the geodns setup for the streaming and by running a local nagios to check the things we need to check. This enabled us to simply tell everyone Use streams.video.debconf.org:8000 wherever you are and you will get to the right server for you. Explaining this in a short way basically goes as “a monitoring tool keeps track of which servers are up and only enables them to resolve. Our geodns server then replies with the right server IPs, depending on in which region of the world you are.”. Which means streams.video.debconf.org will resolve to the local streaming server lisa while you are here, at the same time resolve to a number (those that are up) servers in Europe if you are in Europe or to those in the US if you are there. Nice. (And while I’m already blogging - I do hate my laptops suspend, err - I mean non-suspend mode. Somehow it got worse in the last days, sometimes needing multiple minutes (like 10) to decide to suspend to disk, and the suspend-to-ram still wont work. I should really get someone here that knows this stuff having a look at it. :) ).

Every time I make a new emacs-snapshot release I have to copy the source package from my amd64 desktop to my i386 laptop to build it, then copy the built packages back in order to upload them. This scp'ing gets tiring after a while, so I wrote a trivial script called dscp which acts as a Debian-aware wrapper around scp, using python-deb822. It's similar in spirit to Myon's dget script, which does pretty much the same thing with wget.

Note that unlike scp it can only copy files to other machines, and currently does no command-line parsing at all, so you cannot pass options to scp (other than the user@host:/bla part, of course).

Also note that if the destination is local it will serve as a .dsc/.changes aware cp, which is also handy in some situations.

If there's interest I could probably add some sanity checks and propose it for inclusion into devscripts.

Figures About SVN-Maintained Packages For fun and profit I and gares have just harvested a bit alioth to discover how many packages are currently maintained using subversion. The overall result is larger than I expected 3492 source packages (to be compared with 11786 total packages in unstable) are maintained using Subversion. The numbers might be a bit approximated, I report what we did to extract these number for review. The number of subversion-ed source packages have been computed running on alioth the script harvest source fields.sh (which in turn uses svnlook grep.py) its stdout can be redirected to a .txt file. Once sorted and removed of duplicates you will get something like source pkgs on svn.txt; its length approximates the number of source packages maintained via svn:

$ wc -l source_pkgs_on_svn.txt
3493

The approximation is due to the fact that debian/control are looked for everywhere in a repository, hence it can find old packages no longer in the archive or never uploaded, and some fake package (like "MODULE NAME", but it seems to be the only one). The amount of packages which are in the above list but not in the archive is about 900 packages. Still I don't think it would be fair to exclude all of them since I guess a non trivial part of that are packages that haven't yet uploaded and hence are arguably part of the active development of Debian. Excluding them, the percentage of unstable maintained using SVN on alioth is about 22%. To that you should add the packages maintained using other version control systems. The total number of source packages in unstable have been computed on my laptop as follows:

$ cd /var/lib/apt/lists/
$ ls *Sources
ftp.it.debian.org_debian_dists_unstable_contrib_source_Sources
ftp.it.debian.org_debian_dists_unstable_main_source_Sources
ftp.it.debian.org_debian_dists_unstable_non-free_source_Sources
security.debian.org_dists_testing_updates_contrib_source_Sources
security.debian.org_dists_testing_updates_main_source_Sources
$ cat *Sources   grep ^Package:   sort -u   wc -l
11786

The broader goal was to discover how many packages are maintained using any versioning system on alioth, but we were fluent only in svn internals. Dear lazyweb, feel free to harvest and forward to me your data for the other versioning systems available on alioth, I'll keep this post updated with news.

Right, so as announced I finished my thesis this week. Its translated title is (if anyone want to know)

"Design and Implementation of a Model for the Retrieval of Free/Libre Open Source Software using a Case-Based Reasoning System".

Writing it certainly was an educational experience but I am still happy it's done now. Especially the last weeks where rather unfunny, more so since about ten days before my deadline we had a massive heat wave here in Lower Saxony. Now that it's done I am still waiting for enthusiam to kick in. So far weariness still prevails. Maybe also because finishing my thesis does not yet end my studies. We also have to do written and oral examinations which will take place in July and after. So at the moment I spend my days mostly sleeping and trying to muster up enough wanderlust for my trip to DebConf7. (At the moment the prospect of traveling long distance with trains and cheap flights and then be surrounded by a few hundred happy people is still rather daunting.) Anyway, in order to give an impression of my last weeks and months and to sum this all up, a list of random notes, taken during the last weeks, of what I learned while writing my thesis:

• 6 months are NOT a long time!
• 10.000 chars are not enough to model a Debian package description
• 50 chars are not enough to model a Debian package name (YES, THAT MEANS YOU, libmaypole-plugin-authentication-usersessioncookie-perl!)
• osi.org does not belong to the Open Source Initiative but to Ontario Swine Improvement (Ontario Swine Improvement (OSI) is an industry-run organization dedicated to providing swine improvement and genetic products, programs, information and expertise. Our goal is to help Ontario pork producers achieve competitive advantages and excellence in the global market place.)
• I must not procrastinate.
  Procrastination is the mind-killer.
  Procrastination is the little-death that brings total obliteration.
  I will face my thesis.
  I will permit it to pass over me and through me.
  And when it has gone past I will turn the inner eye to see its path.
  Where the thesis has gone there will be nothing.
  Only I will remain.
• Dr.-Ing. Roland Bless rules! (So does his LaTeX class for theses.)
• Working without internet is possible. It is even better than working with internet. Simply leave gaps where you need to look up stuff and fill them in in the evening.
• Losing half a litre of blood does not impair my fitness for (brain) work.
• Working with version control requires a minimum of intelligence attention. Unfortunately mostly so when ending work (dead tired) and when beginning to work (dead tired).
• Side effects: Insomnia, itchy area on left leg, belly aches, little blisters on the sides of my fingers, headaches, slight but constant petulance.
• "I know what I want to say, getting it on paper is the least work." - WROOOONG!
• German is such a crappy language to write scientific texts in. Special greetings to the generic masculine. Gah!
• When the cat's writing her thesis ...
  The fun time's over now, darling ;)
• "I have don't really like proof-reading your thesis in PDF, can't you just send me the Word file?" is not what you want to hear from your proof reader.
• Good: Debian, vim, subversion, LaTeX, bibtex, evince, xpdf, pdftk, PostgreSQL, OpenOffice.org, dia, gimp, phpESP, tea, coffee, ramen, chocolate, electric fan, eating at the uni's cafeteria twince a day, raw cornflakes straight from the box, frida (my trusty laptop), power naps, pizza, people understanding my true problems, the freedom to burry myself in my work and absolutely and utterly neglect anything else until I am finished.
• The flat can look worse. Much!
• Bad:
  • The FSIL (student council for teaching students) belt grinding(!) tables on the balcony in front of the students' working rooms.
  • People trying to be nice and asking how it's going with the thesis.
  • Fellow students greeting me with "Hey still here?"
  • Our evil DPL blogging about his highly addictive monsterz just when I got to work.
• I'll do it after I handed in the thesis.
• I'll see a doctor about it after I handed in the thesis ...
• I should commit much more often (svn that is)
• How come there are so many extra 'i's in your thesis?" Because it's Linux!
• Sense of time is overrated.
• Print shop guy is mean.
  A = Me, overtired, having formatted and doing last changes to this document the whole night through and on until 20 minutes before the printing appointment.
  B = Print shop guy
  
  B: You know that's not A4 ...
  A: WHAT?!
  B: Yea, it's too big.
  A: WHAT?! But, but, I ... That can't be!
  B: I'm telling you, it's too big. See, 0.3mm too long and 0.12mm too wide
  A: ... *death stare*
  
  
• The examination office is now located in the fourth floor in the building next to the post office at the Hindenburgplatz.
• Tolimar is the most patient and understand guy I've ever known.
  Thank you!
• 6 months are SUCH a long time!

Ben Fowler writes about the issues related to nuclear power in Australia. He spends 8 paragraphs discussing the issues on the “Right” side of politics - of which 6 concern the an Australian nuclear weapons capability and then spends 3 out of 5 paragraphs related to the “Left” side explaining that he thinks that everyone who opposes nuclear power is a Luddite. Ben didn’t bother providing any links or statistics to back up his claims, so I’ll assist him in analysing these issues by providing some facts that we can discuss. In March Spain had wind power provide 27% of all electricity (making wind power the main source of power for the country). I blogged about this at the time. While Spain has an ongoing program of building new wind power stations the majority of wind turbines in Spain are quite old (the Model T of wind power) and not nearly as efficient as modern turbines that would be installed for Australian power plants. The Danish government has announced plans to use wind power for 75% of their electricity. Denmark has a much smaller land area than Australia, which means that generating so much electricity from wind power is more technically challenging for them than it would be for us. A larger land area means that when one area has low wind speeds other areas can be used to provide power. For home electricity generation wind turbines have not yet been proven to be practical. The linear speed of the blade is determined by the wind speed and the rotational speed is therefore a factor of the wind speed divided by the radius of the blades. This means that smaller turbines have higher rotational speeds which causes more noise (bad for getting council approval), also to avoid turbulence a wind turbine will ideally be some distance above the ground (8 meters is good) which again gives problems when getting approval. The O’Connor Hush Turbine is supposed to solve the noise component of this problem. It will be interesting to see whether home based wind power becomes practical in future - if so I would like to get an O’Connor turbine on my house! Home solar power has been proven to work well, in the form of both solar-electric and solar hot water (I know several people who have been happily using them for years). You don’t get cold showers when the sun isn’t shining, you instead use gas or electricity to heat the water (it’s a standard feature in a solar hot water system). Also your home electricity doesn’t go off when the sun stops shining, you have batteries that are charged during sunny times to run things overnight, and when they get flat you pay for power from the grid. It is quite realistic to stick solar power systems on every roof in the country. The added cost to the process of building or purchasing a house is negligible and the benefits include having electricity when mains power is unavailable (NB water is used in generating electricity from coal or nuclear power plants so a bad drought will eventually become a time of limited mains power). Even the smallest home solar electric system will produce enough electricity to power a fridge and freezer 24*7 so it’s a very useful backup for essential power. The government is subsidising the installation of solar electric systems, so it seems that they expect everyone to get one eventually. Dr. Ziggy Switkowski (the main advocate of nuclear power in Australia) says “the introduction of a carbon tax could make nuclear power the cheapest option by the 2020s”. In consecutive paragraphs Ben derides “carbon trading” and claims that nuclear power is “practical”. Unfortunately the main advocate of nuclear power in Australia does not believe that it is practical without a carbon tax. Ziggy also states that it would take at least 15 years to complete a nuclear power plant, unfortunately we don’t have the luxury of waiting for 15 years before starting to try and reduce the damage that we are doing to the environment. The Stern report makes the economic consequences of inaction quite clear. I am not a Luddite. I oppose nuclear power because of the risks related to accidental release of radioactive material and the routine release of radioactive material as part of the uranium mining process, and the dangers related to long-term storage of nuclear waste (let’s not assume that Star Trek science can make it all non-radioactive). Nuclear power is not cost effective for Australia and will take so long to develop that it won’t save us from the serious economic damage predicted by the best scientific models as presented in the Stern report. For large scale power generation wind power works now, can be easily implemented and has no hidden costs or risks. There will never be a Chernobyl type accident with wind power, it is inherently a safe technology. For small scale power generation (something you can add to your home) solar power works well, is not expensive (when considering the price of a house and especially when the government subsidy is counted) and has the potential to seriously reduce the amount of carbon dioxide produced.

Share This

After having been here in Edinburgh for about a week now and not having blogged about it, I'm starting to feel slightly guilty about it. Only slightly so, however. I did figure out that the wireless on my PowerBook doesn't work with 2.6.21, whereas it seems to (flakily) work with 2.6.18. Yay broadcom. Not. Anyway, life here in Edinburgh has been fun so far. Mostly. I had a bit of Mao-playing, some bit of "putting faces to names", a bit of Scotch-tasting (of which I still need to remember taking one (1) bottle home for $BROTHER who really likes the stuff), and a bit of getting-so-drunk-I-woke-up-not-yet-completely-sober-and-decided-it-might-be-nice-to-find-my-bed-again, too. Like I said, mostly fun. The guy puking on my luggage last night wasn't fun, but at least he managed to puke most of it right next to my luggage. But I'll still have some laundry to do, I guess. DebCamp to me isn't about being productive, so much as it is about meeting people and getting to know the environment. But I still managed to do some work on nbd-server, which is now at version 2.9.3 (plus some patches stolen from svn) in Debian. That helps, too. In an hour or two, I'll be doing my m68k got kicked out of etch!?!?! Oh noes! BoF. The schedule already lists 11 people who will be attending, so that's cool. Let's hope we get something productive out of it.

It actually seemed as though I wouldn't be going to DebConf this year. I didn't get to work much the last two months, since I wanted to spend all my time on the near completion of my thesis so I didn't have the money to pay for a flight (or train) to EDI and back myself. Due to that same thesis I also didn't have the time to prepare a talk this year so I was also not a speaker. Since I am also neither a DD nor in NM I was pretty sure I wouldn't be eligible for travel sponsorship this year. And, as expected, I was indeed very far down the queue, so when I still hadn't heard anything about being sponsored until about a week before DebConf was starting I had pretty much given up on the whole thing and resigned to the fact that this year's DebConf would happen without me. However, on 10 June I had a mail in my Inbox. Subject: "Your travel cost sponsorship request for DebConf7". It seems the DebConf team was able to dig up some more money and do another run on the sponsorship queue. This was three days before I had to get my thesis to the print shop and I wasn't really doing anything else except for frantically going over my proof readers' annotations, doing last minute additions, changes etc. and occasionally lie down for a few hours of rather uneasy sleep. So my first reaction was something along the lines of "What?! Now?! I don't have time for this now! Go away!" and I was pretty close to answering the mail saying "Thank's but that's too short notice. I won't be coming, have fun, see you all next year." Luckily Tolimar prevented this though and actually managed to find a flight for me that not only goes on the actual days that I had originally planned to arrive and leave but that is also not far over my travel sponsorship! So, long story short, I'll be flying to EDI on Wednesday. It'll only be for the very last few days and I am probably already missing out on lots and lots of stuff, but at least I'll be able to attend for a few days. And in time for debian-women's third birthday! :) I just hope everything will go well, it seems there's a lot of trouble with flying to DebConf this year, at least judging from what I read on planet and heard on irc. See you all soon!

10:51 -!- Irssi: Topic: -: So: Myon
10:51 -!- Irssi: Topic: +: Transit: Myon

Given the steady stream of "are you here yet?" questions in my irc client, it looks like I will meet a lot of old and new friends in EDI. My flight will leave from DTM at 17:30 today, arriving at 18:15 in EDI. Still pondering if going by train or car, probably the former.

Just stopped off in Derby on the way to Edinburgh. It was a good move in one way, because my inbound train was running over 30 minutes late (diverted due to the floods in the Midlands) and my outbound one is only 10 minutes late... but the manager just announced flooding in West Yorkshire, so I guess we'll see. The inbound train was called Vyjaer Kernewek (or something like that), which was nice to see. Derby was useful in another way (besides a good wifi-enabled light meal at the big blue coffee shop). I bought a laptop case. I didn't plan that when I set off, but by Bristol it was already obvious that I couldn't carry all my widgets in one bag. I also couldn't get the laptop out on the train, for fear of a packing explosion. So, Derby has shops. It also seems to have a market-free market place as the focus of the city centre. There's a view up to the cathedral, a small waterfall... and the Derby Mountain Rescue. I suppose the peaks are near, but mountains? The market wasn't in the marketplace. It seemed to be under cover in two parts. One is in the guildhall and the other is in a shopping centre that seems to have an identity crisis - is it the Eagle Centre, or is it Westfield? - and also has a building site attached that greets you as you approach from the railway. Not good tourist promotion. Until the building site, the City-Rail Trail is signposted well, about 5 minutes walk, but the signposts are a bit odd. I noticed the funny ridges first and dismissed them as an anti-spin thing, but then I noticed some bronze floppy disks (I'll post a photo once I find the right USB lead). Other attachments included spark plugs and glasses. There's no sign explaining it that I saw. What the heck is that all about? Coda: No, it wasn't a good move. Apparently there's more flooding in South Yorkshire, so I arrived about midnight and this is posted the next day. At least I'm having a better time of it than damog, who's stuck in New York and I wonder whether other tales of woe will appear on Planet Debian as people find net access. Now for breakfast and planning the day.

Michael Janssen ask about workflow and git, so I will explain mine. I have three types of git repositories:

• git-svn repositories where I don’t have write access on the upstream subversion repositories.
• git-svn repositories where I do have write access on the upstream repository
• pure git repository only I use for now

For the first ones, I work like this:

• the master branch is always synchronous with upstream trunk
• I’ve one topic branch by modification I’m writing
• most of the time, I only merge master with the topic branch, but from time to time I rebase the topic onto master, and then, I extract the patch to send to upstream, or to publish it

For the second type, well, it is only one project, and I work like that:

• as in the previous case, master is the upstream trunk
• then I’ve some local modification that are not meant to be published, but are needed to easily test the application on my computer (this application use an postrgres bases, and those modification are the change of username and password…) So there is a local branch for this
• over those local modification, I’ve several topic branch, where I do the job.

When I decide to commit my job into the main repository, I then rebase the topic branch I want to commit from local to master, and use git-snv dcommit to commit everything into subversion.
I then rebase the local branch, over the new master, and rebase the different topic branch over the new local one.
In-this project, I also from time to time do some real history rewriting, changing the order of the commit, transforming two commit into one, or breaking one commit into several part, this kind of stuff. for the rest, those project are for now so simple or young, that the problem of the work flow is not one I’ve already have

Tokkee and I are doing the mugshots this year and we need your cooperation. Mugshots are a great way for people to link the name to a face and remember that link even after several years. Liw did this as his project last year and it was great success - many people have now a better way to link a persons IRC nickname to their face which in turn reduces the tension in communication as you can very easily know who is the person you are speaking to.
There are people who avoid the mugshots and i wanted to ask them to reconsider. Mugshots is not a beauty pageant - in Debian people are judged by their merits. Mugshots are useful tools in future on-line communications, tools that could reduce the aggressiveness and flammability in the Debian IRC and mailing lists.
It is not the holy grail, but it helps. So I ask every participant of Debconf - help us make this mugshot gallery complete by contributing your own picture. And thank you very much to the many people that already did.
If you want to have your mugshot taken then listen out to when mugshot sessions are taking place - we take all mugshots in front of the cafeteria door, usually during the food times, so you have easy time finding me and tokkee there. UPDATE: First 120 mugshots are uploaded here. Next mugshot shooting session will be tomorrow - on the 18th of June, during scheduled lunch and dinner.

Lately I have been thinking about switching source code management systems. In years gone by, I have used CVS, Subversion, arch, and most recently bazaar-ng for managing all the source code that I have to change. Lately I have been unhappy with the speed that bazaar takes to get some things done, and after watching a Google talk by Linus about Git, I thought I would give it a look.

I was surprised to find out that it actually models the way that I work normally slightly better than the bazaar model does. The main thing is that a repository holds a bunch of branches, but the working directory only has one of those branches checked out at any point in time. I use bazaar with about 4-5 branches per project, and only work on one of them at once (normally, sometimes I want to transport a bug across a couple branches) - so the "working space replaced by branch you want to work on" actually works out OK for me. I also need to collaborate with a bunch of projects at school and work that use other systems including CVS and Subversion, which Git seems to make it easy to do.

I did run into some questions that I don't really have a good answer to, however, therefore the new segment on the blog: Ask the interwebs. Normally I would just ask on some IRC channel, but the Minneapolis public library doesn't seem to allow anything but HTTP out. On to the question!

When using Git, how do you manage having multiple computers (at multiple locations) that you work on? I have approximately 5 different computers that I use regularly. Luckily I have enough space to have git installed on all of them, and I also have a web server that I can use WebDAV on if necessary. What I would like to have is a repository that I can pull from before I start work (if I am connected) and then push to when I finish so that the next computer I sit down at I can just pull again and get everyting. I would like this to include any branches I may have made on the first computer. Is this possible, hard, or easy for Git users? How much do I need to worry about slowdown? My WebDAV server is in the cloud, and I would prefer to be able to get up and go on say, a minute's notice.

I'm also interested on what your workflow is like even if it doesn't match the model I just described. I'm open to changing - the bazaar-ng to git change is big enough that I can probably incorporate a new workflow as well.

Comments: (8) Trackbacks: (1)

Comments

1. adrian: hi, i'm a just a newbie so can't help much.
   You can host your push repository in http://repo.or.cz.
   If you prefer to do it your own you have git-daemon (Have a look to tutorials). Good luck!
   #1 2007-06-16 13:59 (Reply)
2. Michael Janssen: I looked at the public repo.or.cz, but decided against it, because while I want my branches to be available at some point, I'd rather not all of them at the same time. People randomly finding them is okay, but I'm sure I'll check in unworkable/uncompilable code in this state, because I would basically be using git as an easy sync between computers at times.
   
   I'm just really interested in how other people deal with this issue of needing semi-location-independent access to the branches.
   #1.1 2007-06-16 23:29 (Reply)
3. mike: Sounds already good for you to use git.
   
   Enjoy!
   #2 2007-06-16 15:57 (Reply)
4. R mi Vanicat: I haven't answer to the synchronization problem on my blog post because it is one I don't have. Still, you can make a git repository that can be pull and push from, and git can use https/dav or ssh or its on git protocol for this.
   
   Just read man git-remote, man git-push, man git-pull and man git
   #3 2007-06-17 00:06 (Reply)
5. JM Ibanez: Just upload a bare git repository (e.g. copy /.git in particular) to a server you have ssh access to. Then, in your working copy in git 1.5:
   
   
   <br />
     $ git remote add upstream git+ssh:///path/to/bare/git<br />
    
   
   
   You can then
   
   
   <br />
     $ git pull upstream .<br />
    
   
   
   or
   
   <br />
     $ git pull upstream/some-upstream-branch my-local-branch<br />
    
   
   
   or
   
   <br />
     $ git push upstream/some-upstream-branch<br />
    
   #4 2007-06-17 01:15 (Reply)
6. Josh Triplett: A followup to that: you can do the same thing without ssh access, by using WebDAV. See Documentation/howto/setup-git-server-over-http.txt in the Git source (also available various other places in other formats).
   #4.1 2007-06-17 02:13 (Reply)
7. Steven Walter: Whenever I want to create a non-local git repository for push, whether for sharing the code or just backing it up on another system, I follow this procedure:
   
   ssh remoteserver
   mkdir myproject.git
   cd myproject.git
   git --bare init --shared=all # world readable, group writeable
   chgrp -R git .
   vi description
   exit
   # back on local system
   git remote add origin git+ssh://remoteserver/path/to/git
   git push origin master:master
   git push origin branch2:branch2 # repeat for other branches
   
   You may then want to re-create your local branches so that they "track" the remote branches. "man git-branch" for more details on this.
   
   Hope that helps!
   #5 2007-06-18 04:25 (Reply)
8. brian m. carlson: For your workflow, you can try this:
   [geshi lang=sh]
   # first time on each machine only (you can use DAV, too)
   git remote add server git+ssh://server-hostname/path/project.git
   
   # every time
   git push server
   ssh anothermachine
   git fetch server
   git pull server branch-on-server-to-merge-from
   # merge happens; continue working
   # start over again from the push
   [/lang]
   #6 2007-06-18 09:56 (Reply)

Trackbacks

1. How I use git
   Michael Janssen ask about workflow and git, so I will explain mine. I have three types of git repositories: git-svn repositories where I don’t have write access on the upstream subversion repositories. git-svn repositories where I do have write ...
   Weblog: Debian, and other stuff (Tracked: Jun 16, 23:49)

Many manuals of installing and using World of Warcraft (or simply WoW) in Linux using Wine (Windows emulation) are outdated and provide lots of complex instructions for old Wine version. The truth is very simple:

1. Take a recent Wine version. Any version from this year (2007) will do. Debian and Ubuntu users can either use the wine from the latest releases of the distros or use the winehq.org repositories.
2. Install WoW via the usual installer
3. Edit $WOW/WTF/Config.wtf and add following lines:
   
SET gxApi "OpenGL"
SET SoundOutputSystem "1"
SET SoundBufferSize "100"

4. Run ‘wine regedit’ and set HKEY_CURRENT_USER->Software->Wine->OpenGL->DisabledExtensions to “GL_ARB_vertex_buffer_object” (you will need to create this string value)

That is it! You can now simple run ‘wine WoW.exe’ and play the game. Updates also work perfectly. The speed is a bit faster then in the other operating systems and (just like in MacOs X) you can have all your software opened on one virtual desktop, WoW on another and switch between them instantly.

Debcamp is productive Shame on me for having underestimated the productiveness of DebCamp/DebConf. This year I'm overwhelmed by things to do and the first (for me) 2 days of DebCamp have really been productive. Yesterday the Zenoss packaging has taken off. We have already implemented (thanks to Fabio) the needed changes in dzhandle to properly handle ZEO databases, added user management for the zenoss system user, updated the documentation and we started working on the dbconfig-common stuff (we also have just noticed that Seanius, dbconfig-common author, is arriving tomorrow at DebConf, what a great occasion!). Today I've worked more on the OCaml packaging side. A first working version of OCaml 3.10.0 is now available in experimental .. ehm, oops, I meant in the NEW queue; CamlP4 available in there has been finally properly split into (huge) pieces and people can start rebuilding OCaml packages against it. Next day, actually hour, exciting adventures for me include:

• Vim packaging stuff (Jamessan has just arrived in EDI as well, and we plan to both kickstart the Debian Vim policy and to do some vim-specific BSP)
• OCaml automatic dependency handling stuff. In a few minutes me, Gildor, and Jcristau will brainstorming about that ... somewhere in this castle.

Wow, I'm overwhelmed, but it's actually soooo fun!

OK, after fighting with the Edinburgh traffic / roadworks, I'm finally in-situ and online. Just going to go and find the venue, get badge, etc., ready for the full start tomorrow. (My first DebConf!)

One of the reasons I tend not to blog very much is that I don't have much to say to the Planet Debian audience (the only place I know my blog is syndicated) that hasn't been said a dozen times before. But the world's best release party (the one good enough to cross an ocean for) gave me food for thought, and for once I'm inspired in the true spirit of blogging to write even if nobody cares what I have to say. Even if it has taken me until two months after the release to write it... Folks within the Debian community have been asking for years whether it's really still worthwhile for Debian to do stable releases, or if we're better off focusing on our "core competency" of testing and unstable and leaving stable releases to derivatives. For me, the answer to this question is an unqualified: yes, it's worthwhile. Of course that's the answer you'd expect from a release manager. Who would want to believe after committing as much time as the release team does that their efforts had been wasted? But the investment I've made in the etch release wasn't done without reflection; I recognize that the level of involvement required to be a release manager has come at some personal cost to me, as it does for each member of the release team, and I have made the investment anyway because I believe in Debian's philosophy, its goals, and its community. Even outside of a stable release, Debian packages really are great; in spite of the bugs and library transitions that we as release managers spend our time on in unstable and testing, and figures showing that within a month of the etch release we already had some 500 RC bugs identified for lenny, both unstable and testing do a great job of meeting the needs of many of our users. And package maintainers are constantly improving their packages in unstable, fixing bugs and adding new features. Unstable is a flowing river, vibrant and vital, never the same twice -- and only rarely are people dragged to their deaths by the undertow. ;) Maintainers often don't get to choose the version of their package that goes into stable. When it comes to a stable release, the bug you know is quite often better than the bug you don't. But although the release team is charged with chasing out the release-critical issues in preparation of a stable release, it isn't just the release team who deserves credit for etch. Etch is a monument to the work of all Debian maintainers, who have each helped shape the release with their contributions. "Stable" doesn't mean "perfect", but it does mean "lasting": in etch we have not only created what I think is the highest-quality OS I've ever had the privilege to be involved in, we have created something permanent that will be burned to thousands or millions of disks, something that users will continue to use and install for years to come. Far from standing in opposition to unstable, it is a perfect complement, letting us share everything that's great about Debian with users for whom tracking a constantly-changing testing or unstable simply isn't an option. I had decided well before etch was finished that it was time for me to move on from serving as release manager, but I still look forward to great things from Debian stable for lenny and releases beyond. With last weekend's release team meeting in Juelich, and the wonderful collaboration that's sure to take place this week at DebConf 7, I think we're off to a great start. The grumbling on IRC about broken packages and missing builds and uncoordinated library transitions is already in full swing for lenny -- and I'm no small contributor to that myself even now -- but we shouldn't let that blind us to what a great achievement etch has been for the Debian community, and what a great achievement lenny will be when it's released exactly on schedule next year.