• No products in the cart.

Reporting Bugs and the BSD Community by Randy Westlund

Picture source QAtabBlog

Last time I wrote about Moving to FreeBSD. Now that I’ve been using it for a while, I have more to say.

There was a time when I didn’t report bugs. I was lazy. I didn’t want to invest the time trying to diagnose the problem, so I worked around it. I would use a different program. I would bump whatever I was doing to the bottom of my TODO list and try building it again in a week or two. It would get fixed eventually. Probably.

That wasn’t very good of me.

I’ve been using Linux for the past several years and BSD for the past few months. I love the open source community. I’ve benefited immensely from this wealth of knowledge, code, and cooperation. I write lots of code including C, but not for any major open-source tools. I’d never contributed to an operating system. But I wanted to give something back.

I spent time brainstorming ways in which I could contribute back to the community. I made lists of all the tools and programs that I use and rely on. But none of them jumped out as things I would enjoy working on.

So I tried to think of new programs that were needed. But that never went anywhere. I never had that much time, and couldn’t think of anything that was needed anyway.

I didn’t want to keep being such a freeloader, but didn’t know what to do about it. I don’t think this is unique to me, which is why I’m writing about it. There are threads on slashdot about it and websites dedicated to connecting coders with projects. But many times, figuring out how to contribute is not so easy.

When I started using FreeBSD, I appreciated the greater emphasis on documentation, correctness, and proper design. It was refreshing. My operating system felt more professional, and I wanted to be part of the community in a way that Linux never pulled me in.

The FreeBSD documentation has a great article on how to contribute. So I decided that I was going to start reporting bugs. I read about how to file a PR. I was going to spend a little extra time investigating problems I came across, and I could both get my problem fixed and make FreeBSD better. What a great deal!

One of my many hats is as an embedded systems engineer. Any time you use an OS on an architecture that isn’t mainstream, you’re going to run into more problems than normal. Maybe someone enables a particular compiler flag, but has no way to test it on ARM. Even if they did, it’s a time-consuming process that requires hardware and a build environment.

To date, I’ve filed seven PRs for FreeBSD, most of which relate to ARM. Three are fixed, three are just waiting to be committed or for someone else to respond, and one is a kernel issue that probably won’t be fixed until I can figure out how to debug and fix it myself. One of my standing goals is to learn enough to resolve all the PRs I’ve opened.

One PR was fixed and committed in less than 20 minutes! My productivity was barely affected. Sometimes it’s faster to report the bug and get it fixed than it is to work around it.

The next step for me is to start submitting patches with my PRs. I’ve been reading the Porter’s Handbook, and these makefiles are starting to make sense to me. The differences between BSD make and GNU make still throw me off sometimes.

I’ve been reading other books as well. I read FreeBSD Mastery: Storage Essentials by Michael W Lucas and I’m almost done with FreeBSD Mastery: ZFS by Michael W Lucas and Allan Jude. Both wonderful books that save you many days of scouring man pages and Google.

But the big one I’m reading is The Design and Implementation of the FreeBSD Operating System by Marshall Kirk McKusick, George V Neville-Neil, and Robert N.M. Watson. It’s a textbook that focuses on the kernel. It’s dense material and it’s going to take me a while to get through it, but the information is presented well. Operating system design has been interesting to me recently, and I like how the book walks me through all the design decisions in the kernel, and the history of how it happened.

I’m learning all this because it’s fun and interesting, but also because I want to be part of the community. I’d like to earn my way to being a committer. I feel this way because the BSD community is friendly, professional, and knowledgeable. It’s a meritocracy. Everything the Linux community isn’t, but should be.

So please, report bugs. No matter what operating system you use. Even if you’re not sure how. Don’t be a freeloader. Participate in the software you use, and make it better.

publicpreview-1.phpBio: I’m an engineer and open source advocate living near Cambridge, MA. I do a lot
of freelance work and work from home most days.

My areas of focus include electronics, PCB design, microcontrollers, robotics,
Linux, BSD, system administration, web design, and RF communications.

I’ve been to Antarctica twice, doing satellite communication work for NASA.

I’m a licensed amateur radio operator, callsign KK4DOP.

In my spare time, I enjoy hiking, photography, and running BSD servers on
computers other people throw away.

Source TextPlain

Twitter @randy_westlund

LinkedIn Randy Westlund

Let us know, what do you think about the article in the comments down below!

0 responses on "Reporting Bugs and the BSD Community by Randy Westlund"

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013