I recently found out a few awesome tricks for git send-email that have made my life much easier, so I decided to share them here

First, git send-email is an essential tool in every git guru’s arsenal, as it’s the preferred way of submitting patches. All you need to do is generate your patches with git format-patch (preferably with a cover letter), and then use git send-email to send those patches inlined in a nicely formatted email thread with your MTA.

But do you know about the different threading formats, address-book queries, or the cc-cmd option? No? Well, let’s get started.

Threading formats

By default git uses the deep threading format, which looks somewhat like this:

foobar patch 0
+-foobar patch 1
  +-foobar patch 2
  | +-foobar patch 3
  |   +-foobar patch 4
  |   | +-foobar patch 5
  |   +-comment on patch 3
  +-comment on patch 1

This looks really nasty, specially for very big patch series. That’s why for v1.7.0 the default format would be the shallow one:

foobar patch 0 (usually a summary/overview)
+-foobar patch 1
| +-comment on patch 1
+-foobar patch 2
+-foobar patch 3
| +-comment on patch 3
+-foobar patch 4
+-foobar patch 5

So, if you want to be nice with your patch reviewers, all you have to do is:
git config --global sendemail.chainreplyto false

Read Junio’s email for more details.

Address-book

Sometimes it becomes tedious to manually specify each person’s name and email address in the command line, such as:
git send-email --to "John Doe <john.doe@gmail.com>" *.patch

That’s why git send-email has a nice feature called ‘aliases’. With this, you can use your address-book from MUA’s such as mutt, mailrc, pine, elm, and gnus. Once you configure ’sendemail.aliasesfile’ and ’sendemail.aliasfiletype’ properly you don’t have to type emails again:
git send-email --to juha --cc mark --cc rene --cc marco *.patch

cc-cmd

Now, sending an email to a mailing list might not be enough to get your patch accepted, so you probably want to CC the right people, but finding them usually takes some effort. That’s when ‘cc-cmd’ comes to the rescue. With the ‘cc-cmd’ option you can specify a command to run for each patch being sent; each line generated by this tool will be a person to be CC’ed.

For example, suppose I have a script that magically finds the people to CC:
magic-script 0001-simplify-the-user-configuration.patch
"Dan McGee" <foo@bar.com>
"J. Bruce Fields" <foo@bar.edu>

When I run:
git semd-email --cc-cmd magic-script 0001-simplify-the-user-configuration.patch

Dan and Bruce will be automatically CC’ed.

Pretty neat, huh? Now the only missing piece is the actual magic script. The Linux kernel has one called ‘get_maintainer.pl’, which is awesome, but it only works on their code-base, and unfortunately there doesn’t seem to be a generic one… until now.

The magic cc-cmd script

Suppose we have the following patch:

--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -985,9 +985,8 @@ easiest way to do so is to make sure the following lines appear in a
 file named .gitconfig in your home directory:

 ------------------------------------------------
-[user]
-	name = Your Name Comes Here
-	email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
 ------------------------------------------------

 (See the "CONFIGURATION FILE" section of linkgit:git-config[1] for

Who should we CC in order to get this patch accepted? Well, probably the people that have touched those lines before. Fortunately git blame makes it easy:

git blame -L985,+9 -- Documentation/user-manual.txt
58c19d1f J. Bruce Fields file named .gitconfig in your home directory:
d19fbc3c J. Bruce Fields
d19fbc3c J. Bruce Fields ------------------------------------------------
d19fbc3c J. Bruce Fields [user]
d19fbc3c J. Bruce Fields name = Your Name Comes Here
d19fbc3c J. Bruce Fields email = you@yourdomain.example.com
d19fbc3c J. Bruce Fields ------------------------------------------------
d19fbc3c J. Bruce Fields
5162e697 Dan McGee (See the "CONFIGURATION FILE" section of linkgit:git-config[1] for

Bang! That’s exactly what we need. For each chunk the patch is touching, we get the authors, and put them in the CC list. That way not only we make sure that the patch gets accepted, but also that the changes are properly reviewed.

I wrote a script that does exactly that, you can find it on gist.github.com.

Final notes

Here’s my example configuration for the git project:

sendemail.aliasesfile=/home/felipec/.mutt/aliases
sendemail.aliasfiletype=mutt
sendemail.chainreplyto=false
sendemail.to=git@vger.kernel.org
sendemail.cccmd=git-cc

Usually my patches are on top of the ‘master’ branch, I always add a cover-letter, and review them before sending, so:
git format-patch --cover-letter master
git send-email --annotate *.patch

If you don’t have a decent MTA, you can use msmtp to send your patches through Gmail, so really there’s no excuse not to send your patches properly

So let’s march and send patches all over the Interwebs™ powered by git

It took me a lot more than I expected, but I finally managed to get the beagleboard booting and happy with the latest linux kernel (2.6.32-rc3), DSS2, and dsp-bridge driver.

And then I could run gst-dsp: a native GStreamer plug-in to access Texas Instruments’ DSP algorithms for OMAP3 platforms. Which marks the time for making a public release.

Here’s the video

The video playback is running on the beagleboard with gst-dsp and gst-omapfb (no X) with TI public DSP binaries; it’s a WVGA (800×480) MPEG-4 video. It’s not running as smoothly as I wanted; it seems the public binaries are a bit buggy, and there’s some problem with the dsp-bridge driver writing directly to the framebuffer, but at least it somewhat works

The video recording is done with an N900, official system (which uses gst-dsp ), and the resulting video is ; 848×480 MPEG-4.

You can find the demo image for the beagleboard, along with instructions, here.

The kernel code is on gitorious; the important tag is v2.6.32-felipec1.

And gst-dsp is hosted on Google Code, although the git repository is actually on github.

The code wasn’t written from scratch, TI’s projects: tiopenmax and libbridge, helped a lot.

And of course many other people made the first release possible (see the shortlog at the end).

Enjoy

Andriy Shevchenko (1):
      base: fix a crash on send codec data

Felipe Contreras (180):
      Initial commit
      Register dsp node
      Add README
      Fix and update copyrights
      Add ALLOCATE_HEAP and ALLOCATE_SN to dsp_bridge
      Add handy dsp_send_message
      dummy: use dsp_send_message
      Rename gstdsp.* to plugin.*
      Makefile: cleanup
      dummy: trivial clanups
      Add log utility
      Use log utility
      dmm_buffer: size_t improvements
      dmm_buffer: always unmap when freeing
      dmm_buffer: use getpagesize()
      dmm_buffer: alignment improvements
      dmm_buffer: add user_data field
      Add MPEG-4 video decoder
      README: update
      mp4vdec: trivial cleanup
      mp4vdec: send signal to output_loop
      mp4vdec: flush output buffers too
      mp4vdec: reset output port
      mp4vdec: extra check for null buffer
      mp4vdec: use atomic operations for status
      mp4vdec: use more atomic operations for status
      mp4vdec: send stop signal before
      mp4vdec: re-use comm buffers
      dmm_buffer: reorganize a bit
      dmm_buffer: add dmm_buffer_reserve
      dmm_buffer: allow to re-reserve memory
      dmm_buffer: allow re-mapping
      mp4vdec: trivial cleanup
      dmm_buffer: unmap before unreserving
      mp4vdec: re-use mappings for output buffers
      mp4vdec: convert flush condition to semaphore
      Remove cond.h
      Rename mp4vdec to vdec
      vdec: trivial cleanup
      vdec: trivial reorganization
      vdec: prepare for multiple algos
      vdec: move create_node to dsp_start
      vdec: start dsp node after getting the caps
      vdec: initial support for H.264
      vdec: add Juha to authors list
      README: update
      vdec: cleanup
      vdec: make dsp_thread static
      vdec: reorganize a bit
      New base class
      Add new video encoder
      base: handle more commands
      base: reorganize got_message a bit
      venc: improve jpeg args
      venc: send jpeg dynamic params
      base: cleanup setup_output_buffers
      base: remove unused buffer_count
      base: reorganize a bit
      base: add use_pad_alloc option
      base: free mapped buffers on dsp_stop()
      base: be more verbose on get_slot()
      README: update
      Makefile: check for missing symbols
      New utility gstdsp_register()
      base: detect dsp errors
      base: properly handle dsp errors
      base: post error in the bus
      base: extra check for status in outout_loop()
      base: free events array
      base: reinitialize state on NULL->READY
      base: use circular buffer for timestamps
      base: increase ts_array
      base: increase mapping cache
      dummy: reorganize map_buffer
      dummy: input buffers don't need alignment
      dummy: cleanup
      dummy: don't map buffers
      venc: increase framesize limit for jpeg
      base: add gstdsp_post_error()
      venc: allocate a buffer when framesize is unaligned
      base: decrease wait for events timeout
      base: more error messages
      base: re-initialize on READY->PAUSED
      base: don't panic on wrong status
      base: destroy node at the right time
      base: catch playback completed message
      base: possible memleak fixes
      vdec: send codec data for MPEG-4
      base: make map cache optional
      plugin: set more proper ranks
      vdec: add framerate workaround
      vdec: remove gstdsp_send_buffer()
      base: add create_node() vmethod
      base: add parsing facilities
      Add h263 parser
      parse: update framesize only when unset
      Random cleanups
      base: add support for stream params
      venc: add H.263
      venc: use h263 by default
      Reorganize encoders
      base: send codec data for all the codecs
      base: keep trying if parse func fails
      base: trivial cleanup
      Trivial cleanups
      log: don't display info level
      log: decrease log level for buffer allocs
      log: add pr_test
      base: rename array to cache
      base: rename 'buffer' to 'comm'
      base: event cleanup
      base: reorganize a bit
      base: assume output buffer is always there
      base: remove out_buffer, use port buffer
      base: store input buffer
      base: trivial cleanup
      base: flush ports on stop
      base: plug some possible leaks
      base: make map_buffer() more conservative
      base: trigger semaphore after buffer modifications
      base: re-use input buffer
      base: add port index field
      Add async queue
      base: allow multiple buffers
      base: allow child elements to configure the ports
      vdec: increase the number of buffers to 2
      venc: trivial fixes
      log: add missing include
      base: re-enable queues properly
      venc: decrease input buffer size
      base: wait for eos
      base: possible fix
      Initial MPEG-4 video encoder support
      gstdspvenc.h: preemptively add H.264 to the list
      base: add send_codec_data() helper
      vdec: use send_codec_data()
      vdec: extra checks
      Add skip hack
      Revert "venc: forcing mpeg4 I frame each i_frame_interval"
      venc: reorganize stream/dynamic params
      base: trivial cleanup
      base: properly set param virt addr
      Add param argument to buffer callbacks
      Add buffer argument to buffer callbacks
      base: add buffer recv_cb
      base: add check for end addr alignment
      vdec: fix extra unref for codec-data
      base: trivial cleanups
      Rename dmm_buffer_flush() to dmm_buffer_clean()
      base: fix memory read
      dmm_buffer: clean instead of flush
      dmm_buffer: add cache 'flush' function back
      Use more proper cache functions
      base: handle bad node termination
      base: make EOS alignment an option
      jpegenc: enable eos align
      venc: improve integer framerate calculation
      venc: fix bitrate calculation
      venc: cleanup bitrate calculation
      venc: remove jpeg from bitrate calculation
      venc: tweak bitrate calculation
      venc: trivial cleanups
      venc: add 'quality' field
      venc: calculate smaller buffer sizes
      Fix some static analysis warnings
      log: avoid pr_info when gst debugging is off
      base: remove use_map_cache
      Trivial cleanups
      Cleanup type registrations
      base: improve some compiler hints
      dmm-buffer: check cache flush size
      base: properly free node resources
      Create custom dsp_node_t
      dsp-bridge: store node heap ourselves
      dsp-bridge: store node msgbuf ourselves
      dsp-bridge: cleanup node_free
      base: copy buffers when appropriate
      base: remove unnecessary cache flushing
      venc: set rate-control to variable
      base: post critical error mesages to the bus

Hoseok Chang (1):
      venc: tune mp4v parms for better performance

Juha Alanen (5):
      vdec: set profile based on the frame size
      vdec: improve H.263 args
      vdec: initial support for WMV9
      venc: set profile correctly for H.263 and MPEG4
      venc: disable single scan output for JPEG encoder

Marco Ballesio (8):
      vdec: fix srcpad setup
      venc: rename mp4venc_stream_params
      venc: add mp4venc_out_stream_params
      base: use proper buffer length
      venc: forcing mpeg4 I frame each i_frame_interval
      venc: reordered mp4venc_args initialization
      venc: added bitrate computation formula
      venc: propagate keyframes properly

Mark Nauwelaerts (2):
      base: safer buffer allocation and freeing
      base: fix element ref leak

Miguel Verdu (2):
      venc: tune MPEG-4 parameters
      venc: tune MPEG-4 parameters for quality

René Stadler (3):
      base: fix thread leak
      base: advance timestamp pointer for empty output buffers
      base: don't use DSP flushing

Tim-Philipp Müller (1):
      base: unref unused output buffer when skipping output

So codeswarm.rb has now been renamed to ripary and got some project hosting.

In order to celebrate I created a visualization of linux 2.6.31 development.

Here it is:

Next step is to figure out a way to render videos that don’t look so crappy on YouTube

We are we so different from the chimpanzees? We are naked bipeds. Why? The Savanna theory has recently been found to be quite unlikely. So what are the alternatives?

So, it looks like Pidgin developers have a little trouble believing that I’ve
contributed substantially to the msn prpl, so I decided to prove it once and
for all.

I took the latest code from the pidgin-clone repo and ran git bisectgit blame, which
returns the latest commit that touched each and every line of code. Then I read
every commit message to identify the real author (Pidgin’s mtn has inacurate
information) until I completed 90% of the code (the missing 10% would take too
much effort). Unfortunately a good portion of the code (8%) is mere cleanups so
I decided to remove it from the calculation.

The end result is this:

pidgin-msn contributions

Even after several years of not touching the code, and major updates like
msnp9->msnp14, 42% of the current code came directly from me. But also interesting is
the fact that 20% came from people that are not current Pidgin
developers: typ0, chipx86 and mayuan. So, less than 38% of the code was
developed by current Pidgin developers.

Now I wish Pidgin developers would acknowledge that I’m the one that knows the code-base better, for obvious reasons (I wrote most of it).

The bug we are talking about is the infamous switchboard timeout error which was very elusive, it happened randomly, and very often for some users in unknown conditions. Essentially you send a message, and after one minute you receive a notification telling you the message never arrived, after which you need to resend the message, and hope it will arrive this time.

Let’s see how the two projects approached this bug.

Pidgin

There have probably been many bug reports regarding this issue, but it’s very difficult to find old historic bugs in Pidgin’s new and old tracker. The modern version is reported in Pidgin’s tracker as #3330. There you can see people saying it happens a lot, that the priority should be increased, and many tickets were marked as duplicate. Developers however stayed in denial mode: they say it doesn’t happen to them, and then turn to the usual strategy: ask for irrelevant information such as a valgrind log, and to try again as it might have been magically fixed.

Then they try a simplistic workaround; re-send the message on failure. This doesn’t work on most cases, and even when it does, the message arrives more than 1 minute late. As usual, no developer did much else about the bug.

In the mean-time, Adium had many reports (2475, 2395, 6316, 6708, 6952, 7288, 9978, 11045, 11398, 11478) of the same bug. At this point something was very clear: it happens more often in OS X.

The interesting point is when Rasmus Hummelmose, an Adium user, logged to IRC to rant about the problem. He received the same response on both #adium and #pidgin; it’s a server problem, or it’s your slow connection, there’s nothing we can do. That didn’t convince him (it wasn’t true) and he effusively tried to explain that the issue was real and was affecting many users. He didn’t achieve anything more than upsetting the developers.

This is not the way to solve an important bug.

msn-pecan

The msn-pecan team on the other hand thought: hey, there’s a bug, and this guy can reproduce it, let’s fix it. I invited him to #msn-pecan. Rasmus was a bit reluctant; Why loose time with msn-pecan developers? Surely Pidgin developers must be capable enough to do the job. He changed his mind when I explained that the core parts of libpurple’s (Pidgin) msn were either developed or refined by me anyway, and therefore, Pidgin devs probably didn’t have the expertise required to identify this problem.

With that we started an endeavour to fix the problem through the weekend. I started by providing some infrastructure changes in order to visualize what was actually happening, Devid Antonio Filoni created Adium builds, and Rasmus tested, and provided feedback. We made some conjectures and discarded them with further testing and fixed some bugs along the way until we found a reliable way to reproduce: send a message, wait for 15 minutes of inactivity, and send another message.

After this is was clear that something bogus was happening with the network connection, but since we cannot fix all the elements involved, we implemented a simple fix: close the connection after 1 minute. That worked perfectly. Rasmus was happy, and we were too

That’s how you do it.

The stealing

Logically after our success, Rasmus decided to rub the fix on the face of Pidgin and Adium developers, after all, they were the ones that said it was not a bug. But they were not impressed.

However, Daniel Ljungborg (aka Dimmuxx) was interested in the fix, and in good faith I pointed the commit message that explains the issue in detail.

Then I find out Ka-Hing Cheung, a Pidgin developer, implemented the fix as I described, but thought it was OK to not thank anybody, explain where the fix came from, or mention the msn-pecan project, or any external source at all. We (Rasmus, Devid and I) spent a weekend of our free time working hard to identify, fix, and verify the issue, and if you read the commit message you would think they came out with the solution:

Author: khc@pidgin.im
Timeout switchboard connections at 60 seconds, should Fixes #3330 for most people.

That is plagiarism, pure and simple, and unfortunately, it’s not the first time.

The next msn-pecan release started as 0.0.20 but there are so many changes that
it’s going to be 0.1.0. It is way more stable than 0.0.19 but we still would
like to do more extensive testing, so we are rolling a release candidate in
order to fix critical bugs that might be lingering. Hopefully it will be the
only release candidate before the actual release.

The aim of 0.1.0 is going to be our “first serious release”, that doesn’t mean
the previous releases were bad, it just means that we were never truly
confident about the code being delivered until now.

Compared to 0.0.19:

• Timeout issues fixed (switchboard error)
• Better offline messages receiving support
• Offline message sending support
• Reorganization of P2P code (less crashes)
• Several crash fixes
• Adium improvements
• Performance improvements
• Massive code reorganization

Special thanks for Devid Antonio Filoni, and Andrea Piccinelli who have been
very active fixing issues and making sure msn-pecan is rock-solid. Also Rasmus
Hummelmose who was essential in fixing the timeout issues, it wouldn’t have
been possible without his testing. Also thanks to the Pidgin developers (we
picked some patches), and many other contributors.

This is the list of issues fixed so far:

• 37: Pidgin leaves handle on files after transfers
• 82: Implement sending of offline messages
• 117: Received offline messages are being cut
• 138: Translation is not whole integrated from Launchpad
• 144: Unable to chat after message timed out
• 155: Pidgin crashes after connecting (using NTLM Authorization Proxy Server)
• 156: msn-pecan crash in msg_ack() at cvr/slplink.c:321
• 157: msn-pecan crash in msn_switchboard_can_send() at switchboard.c:779
• 158: msn-pecan crash in msn_switchboard_free() at switchboard.c:262
• 159: Pidgin crash when connecting to MSN
• 161: 0.0.19 ubuntu package
• 163: Translations not working on win32
• 164: msn-pecan crash in pecan_contact_get_personal_message() at ab/pecan_contact.c:616
• 170: Crash upon sign in
• 171: crash when disabling account
• 174: Windows 7 RC and Pecan
• 177: Offline messages of blocked contacts should not be displayed
• 181: Too many timeout messages
• 183: msn-pecan should use audio:// links with pidgin 2.6.0
• 184: already showed OIM message show again using another client
• 185: Add support for receiving winks
• 133: pidgin crashed with SIGSEGV in msn_message_destroy()
• 154: Pidgin Randomly Crashes
• 166: proxy authorization support missing
• 153: User Adding Problems

The diffstat is huge:

44 files changed, 3423 insertions(+), 3116 deletions(-)

For the source tarball, win32 installer and maemo package check the usual location:
http://code.google.com/p/msn-pecan/downloads/list

And the Adium build is here:
http://code.google.com/p/msn-pecan/wiki/AdiumBuilds

So, start the testing! And please report back any issues

Here is the current list of pending issues for 0.1.0 final:
http://code.google.com/p/msn-pecan/issues/list?q=label%3Amilestone-0.1.0

Finally here’s the shortlog:

     6  Andrea Piccinelli
     1  Chris Stafford
     1  David Geary
    29  Devid Antonio Filoni
     1  Devid Filoni
     4  Elliott Sales de Andrade
   214  Felipe Contreras
     2  Mike Ruprecht

This is somewhat a response to the post “Let’s all take a deep breath and get some perspective” which criticizes Google mostly on the basis of the “failures” of Android and Chrome. But also, everyone is talking these days about Google Chrome OS, and how it is a silly idea. Is that so?

Android

First of all let’s start with some basics: phones take years to develop, Google Android’s first release was on September 2008. Do people seriously think the fact that there are very few phones running Android says anything at all? Not even a year has passed! Also, there was a public statement saying that there will be 18-20 Android phones by the end of the year… that’s right 20.

Also, I personally believe that the 48 members of the Open Handset Alliance are not idling waiting for their companies to be ruined in this economically dangerous time. Their best hope is to put all the chips on Google Android, and they are probably either doing, or planning, just that.

Maybe, just maybe, it would make sense to criticize Android after it has played it’s strongest cards, and not before.

Chrome

It is hard to measure the success of a browser but a conservative figure says that it has taken at least 1% of the global market, that might not seem like a lot, but it’s enough to put it on the 4th place. The browser is less than one year old, and it’s already figuring among the most popular browsers.

Yet some people say it’s a failure, that nobody is using it. Well, compared to Firefox surely much less people are using Chrome, but still it’s less than a year old, most of my bug reports on Firefox are at least twice as old, and some even older. On the other hand, it’s actually nice to see my bug reports on Chromium fixed after weeks.

Not to mention that Chrome is using WebKit, a technology many players (Apple, Nokia, GNOME, Adium, etc.) chose instead of Firefox’s Gecko, perhaps with good reason.

So if I have to bet, I’d bet that Chrome will eventually catch up with Firefox and then surpass it quickly. It’s just a matter of time.

Chrome OS

Finally, let’s talk about Chrome OS. For starters, nothing specific has been said, the announcement was just a publicity move to shift eyes towards Google. You cannot draw any conclusions because nobody knows what Chrome OS will look like. Will it be too simple? Will it have eye-candy? Will it be fast? Will it be reliable? Who knows.

What we do know is that it will use the Linux kernel. The kernel is by far the most complicated part of an Operating System. Sure, there’s a lot of things in user-space too, but you can make mistakes on user-space that you just can’t do in the kernel. And yeah, they’ll have to make a few changes to the kernel too, but that doesn’t take nearly as much effort as starting one from scratch.

Now the question is what will they do on user-space? Maybe they’ll write a simplistic piece of software that will re-invent the wheel that open source has been developing over decades. Or maybe they will come up with a innovative outside-the-box design. There’s really not much point in speculating.

What I’m thinking is that a computer with Chrome OS (and Chrome), Internet access, and Google Wave, will probably be more than enough for newer generations of kids that don’t have our preconceptions of what software should do, in fact, perhaps it will be much better than our current situation.

If you consider the big picture, I think every move from Google is strategically sound. There are huge risks, but if they succeed in their latest endeavours (they usually do), they’ll dramatically change the software game as we know it. I’m eager to see what these nay-sayers think one or two years down the road.

I finally managed some time to make another libmtag release. This is mostly tiding up the code, cleanups, new codestyle, building improvements and moved to github

Also some handy features:

• strip tag: now you can remove say id3v1 tags while keeping id3v2 intact
• get specific tag: similarly, you can retrieve only id3v2 information
• get all: this function might is useful for some UIs, specify some callback, and get all the tags

I wonder why not so many people are using this, is there a better tagging library?

Any packagers interested?

Grab it while it’s hot

Thanks to Devid, we now have a build of Adium with msn-pecan, see the announcement at cocoaforge.

Enjoy