Since I started to use email to send patches (thanks to ‘git format-patch’ and ‘git send-email’) I’ve never looked back. Using email to send, review, and merge patches is superior to anything else, including bugzilla, and here I’ll mention the most important reasons.
Contributing convenience
Who doesn’t find email convenient? Chances are you have an email account, and a SMTP server to send email with, then all you need to do is configure ‘git send-email’ (once), and you are ready to contribute patches to any project. A typical workflow is: ‘git clone’, commit some patches, ‘git format-patch’, find project’s email address, ‘git send-email’, done.
Proponents of bugzilla argue that submitting patches there is equally easy; all you need is ‘git bz’: an utility to automate common tasks, such as bug creation, and attaching new patches. This sounds good in theory, however, unlike what you might think, most proponents of ‘git gz’ don’t even use it, and therefore don’t notice the drawbacks of this approach, mainly: ‘git bz’ is not really mature.
If you manage to get ‘git bz’ working (took me quite a while), then you stumble with another problem: you need a bugzilla account for every project you want to contribute, and of course, you need to configure ‘git bz’ to use each bugzilla account. But wait, I’m not talking about tracker, product, and component, but also default field values, such as assigned-to, operating system, platform, version, priority, and even whether https is used or not. Unfortunately, ‘git bz’ doesn’t even allow to configure these fields, so you would need to patch it. And finally, you need to login to the respective bugzilla with your configured browser before using ‘git bz’.
So no, ‘git bz’ is nowhere nearly as convenient as ‘git send-mail’. In fact, anybody suggesting it without trying it is making a disservice, so please, don’t.
Distributed
If you know anything about git, you know that being distributed is a defining factor. It only makes sense that the patch flow is also distributed; for example, if Turk creates an internal repository for his company team, he should be able to receive patches from the team, and at certain point in time push the patches upstream. It would be ridiculous for Turk to setup a bugzilla server just to receive patches from the team. No, he doesn’t need to do anything, his teammates can use an already familiar channel (email) to send the patches.
As I mentioned, I had to patch ‘git bz’ just to make it work, it took me a whole day, and after that I was so happy with the result that I decided to contact the author and send him the patches, and I did; through email. Isn’t it ironic that the only way to contribute to ‘git bz’ is through email patches? After all, it’s just 2K lines of code, does it really deserve it’s own component in say, GNOME’s bugzilla?
My patches were ignored, and the last commit was 3 months ago. To this date I don’t know what’s the recommended way to contribute, so if you want to take a look at my repo here it is, but honestly, I don’t see much hope for this project.
In conclusion, patches in bugzilla is an awful way to work in a distributed manner, and also for small, or new projects.
Scalability
Teams that use bugzilla usually work on a centralized manner: there’s a team of “official” developers who have commit access to the central repository, and outsiders must submit patches through bugzilla. This is a very traditional way of working, however, has two big disadvantages.
First, being an outsider means each commit will be painful, therefore, even if you are perfectly comfortable with the code-base, your commit bandwidth will be very low. If the project is open enough, you will stay in the “outsider” realm for a short time, and when commit access is granted, the real work begins, but still that’s a waste of resources.
Second, “given enough eyeballs all bugs are shallow”, IOW; patch reviews are good. Now, a special mailing list for post commits (in typical CVS fashion) is not good enough, and here I’m going to make a guess; there’s psychological difference between commenting on a change that is proposed, as opposed to a change that is already done; that is, in the first case the other person has to make the change, and in the latter you have to make the change, at least if you want to be a good contributor and make sure the comment is not lost. Most of the time people avoid these “would be nice if…” comments because the change is already done, and think “nah… it’s not that bad”.
Moreover, it creates a messy commit history. For example, it’s not uncommon to see a considerable amount of tries for each patch series in linux (kernel), say 5 tries, before everyone is happy. Multiple commits fixing the previous ones look ugly, and confusing, on the other hand, one commit that’s small nice and clean makes everybody think: this is perfect!
Anyway, the true test of scalability is to let everyone contribute the same way. Would it be sensible for a project to force everyone to submit changes through bugzilla? No, that would be insane. How about email? That’s exactly how many projects work: linux, ffmpeg, qemu, etc.
Reviewing convenience
Suppose somebody goes through all the pain of creating a bug report and manually attaching a patch series, and adds you to CC (hopefully you have a bugzilla account), then, you would receive an email notification, which you most probably will wish you can just reply, but no, you have to click on a link, login to bugzilla, then, for each comment you would have to manually copy the context, add attribution lines, and then your comment.
With email, you receive an email, you reply, and add your comments inline. What’s more convenient than that? Moreover, each patch can be reviewed individually, and have it’s own separate thread, unlike in bugzilla, which comments follow a single continuous line.
Nowadays there’s splinter for bugzilla, which allows to comment directly on the patches, but it’s still nowhere near intuitive as email; the pain of logging in, finding the patch, etc. is all there, as well as the cumbersomeness of comments on top of comments.
Moreover what happens if you are offline? In email: no problem, bugzilla: you are screwed.
Statefulness
So we arrive to the only relatively valid argument in favor of bugzilla: bug entries don’t disappear, so it’s possible to ignore patches for one year, and work on them later on, IOW: “they will not be lost in my inbox”. The immediate counter-argument is: perhaps if the full patch arrived to your inbox it would be harder to ignore it, and easier to just comment on it. But let’s assume that statefulness is desirable for the sake of argument.
First, if the patch is important to the submitter, and it seems to be ignored, the solution is easy: resend. So, important patches will not be lost. Patches are also ignored in bugzilla, and in such cases people usually ping. Here is an example of a patch ignored in GNOME bugzilla for almost 3 years: 426326; chances are gnome-mount will become obsolete before that patch is applied. Aren’t you glad bugzilla is keeping track of it?!
Secondly, if you really want to keep track of all the patches so nothing gets dropped to the floor, then how hard would it be to have a script that parses incoming email? For example, there’s patchwork, which handles all incoming email of a mailing list, provides a web interface, and allows you to keep track of the status of all patches: accept, reject, under review, etc. For example, see the linux-omap patches list. This way you have all the advantages of email, plus the stateful nature of bugzilla.
So, no, this is not an excuse to use bugzilla.
Conclusion
Don’t get me wrong: bugzilla is an awesome bug tracker, but being awesome in one thing doesn’t mean the same will happen on a different area.
It seems people still don’t understand what distributed development means; it means development doesn’t depend on a centralized entity; it doesn’t depend on an “official” group of developers with commit access, and it doesn’t depend on a centralized patch tracker where “official” developers review and apply patches. So, please forget about this historic baggage; email is simple, natural, distributed, and doesn’t discriminate against one-weekend-contributors.
Just like the last 2 years, I joined the FOSDEM fun. Just like every year there were lots of awesome beers, chocolates, waffles and of course conference full of awesome hackers from all over the world & their awesome talks. In short, the same old 'awesome' experience. Also I finally got to meet Jens George (phako) in person. Another thing that went it a totally unusual (and unexpected) direction was my home directory. Here is how it went:
I spent a little time this weekend doing one of the things I've wanted to do for years - eradicate one of the oldest files in Banshee: 
Ooh, the strain.
. It’s ain’t cheap, but it’s currently the only mobile powerful enough for Moovida… we’d love to have Moovida packaged for it one day 
. It’s got the usual goods, Wifi, 5 px camera, GPS, Blue Tooth stereo music, so you can stay entertained while on the road.
can help you make it happen by allowing you to download a book under 60 seconds. Reading just got a whole lot easier with this gadget, so no more excuses (or maybe one more excuse not to exercise).
to share with friends or the whole world via YouTube and Vimeo.
![[Hacker]](hacker.png){kind=small}
![[Planet]](planet.png){kind=small}
