words from a lazy coder
Yes, I admit it, I hate bugzilla. I mean, the bug tracking is something indispensable for every software project, but digging in its web interface for quick searches, I just find it unbearably awful.
But I guess I came across with the right tool for overcome this web madness: pybugz
On the other hand, I’ve to say that I agree about using bugzilla to keep track of patches, it’s a bad idea too. A properly organised mailing list and maybe a patchwork, if the traffic is massive, as helper.
Back in August 2009 I was chatting with my old peers in Mexico, and they told me that they needed a JPEG parser element in GStreamer for their DSP accelerated JPEG decoder. So, I went to bugzilla and found a bug report about the issue and a proposed patch. But the published patch still missed some features so I took it and worked on it.
After attaching my first try, Arnout, the first author of the patch, came with some comments to improve the element. Several weeks after I retook the element and almost rewrote it again. So I was waiting for the OK from a GStreamer developer.
Finally, this week, Stefan review it and pushed it. Sadly for me, I didn’t notice, when I rebased my local commits, squashing my change set into one single commit, that this commit had as author Arnout, not me 🙁
Now the commit is under the Arnout’s credit.
Yeah, sometimes I’m so absentminded.
I want to work on a new plug-in inside of gst-plugins-bad. But also I want to expose my development to a personal GIT repository, so my friends could fetch my changes.
As Linus Torvalds explained once keeping a nice linear regression set of patches above an upstream development implies the use of git-rebase, nevertheless that also implies that I will have to force my pushes and my friends will also have trouble keeping their repositories in sync with mine.
So this is a kind of compromise between be nice with the people who pull your changes, or ease your daily work.