Robert Basic's blog

Posts tagged 'open source'

Bug triage, the paperwork of open source

by Robert Basic on May 24, 2017.

Everyone loves contributing patches to open source projects, adding new features. Some even like to write documentation.

Probably the least talked about way of contributing to open source is triaging issues (I have no data to back this statement, so I might be wrong!).

I do believe however that it can be the biggest help to project maintainers, because with issue triage out of the way, they are left dealing with the “bigger” problems of the project, such as fixing difficult bugs and implementing new features.

Ideally, a good issue report will include the version numbers of the affected projects, a good description of what the user tried to do, what did they experience, expected and actual results, any logs or stacktraces, and even the smallest possible test case that reproduces the issue being reported.

I say ideally, but that’s not always the case. Sometimes the report has a lot less details, does not include version numbers, or any other information that would help identifying the underlying cause of the issue. In those cases someone needs to go through the reported issues and ask for more information.

It’s paperwork

Issue triage boils down to going through the list of open issues for a project and making sure that the reports include as much as possible useful information. If the reporter hasn’t provided everything needed, we should ask them for more details.

If the initial report includes just enough information to start investigating, we could that as well. Start digging into the codebase and try to figure out what’s going on. If the project has automated tests, we can use them to get a better picture of the issue, and maybe even provide a failing test case to the maintainers. Fun fact: this is how I started with unit tests and test driven development - by submitting failing test cases to projects.

When we deem that we have enough information, we can try to reproduce the issue, and confirm or deny its validity.

Some issues are not really issues, but a case of misconfigured library, or documentation not being read fully. In those cases the solution is not to leave a “RTFM” comment and close it. Asking if they read pages X or Y, is a much better approach. It might be that the documentation is not detailed or clear enough, so we need to update our docs.

Sometimes it’s the lack of documentation that is the real issue.

Once we have enough information, we can leave a comment for the maintainers saying that we managed, or not, to reproduce the bug. From there the maintainers can take over and deal with the issue as they see fit. Or we could attempt at writing a patch and fixing it.

Bug? Feature? Support?

Users will open all kinds of reports. There will be issue reports, there will be feature requests, and there will be questions asking for support.

Deciding on which is which is also a part of issue triage. Label them accordingly, so maintainers and contributors will have an easier time filtering them out.

If you are familiar with how the software works, you might provide an answer to a question and help the user, again taking of the load from the maintainers.

No experience required

One of the best things for me about issue triage is that we don’t need to have experience with the project, let alone be experts in using it. Most of this is communicating with others, asking for more feedback, and making sure that the persons who can decide on the reports can do so with least effort required. Of course, having experience does help, but that’s the way with everything in life, I guess.

Besides, this is also a great opportunity to learn more about the project and the ecosystem around it.

While the work is not grandiose, it will help in getting better at communication skills, it will help the project to move forward just a little bit faster, and it is a great way to contribute to open source projects.

Happy hackin’!

P.S.: Sometimes if you wait long enough, the reporter won’t even remember what the issues was, and they’ll just close the issue.

Tags: bugs, contributions, issues, open source, triage.
Categories: Blablabla, Software.

Open source taught me how to work with legacy code

by Robert Basic on April 28, 2017.

Contributing to open source projects has many benefits — you learn and you teach, you can make friends or find business partners, you might get a chance to travel. Even have a keynote at a conference, like Gary did.

Contributing to open source projects was the best decision I made in my professional career. Just because I contributed to, and blogged about Zend Framework, I ended up working and consulting for a company for four and a half years. I learned a lot during that time.

What I realized just recently is that open source also taught me how to work with legacy code. It taught me how to find my way around an unknown codebase faster, where to look and what to look for when investigating an issue. Most importantly, it taught me how to react to legacy code.

Usually when people hear “legacy code”, they think code that was written by a bunch of code monkeys who know nothing about writing good software. The past was stupid, the present is smart and wise, and will make everything better for the future. A long time ago, I was the same.

Today, my thinking and my approach is completely different.

I have the utmost respect for the programmer and their code that is before me. Rarely do I have the privilege knowing the circumstances under which a piece of legacy code was written.

In many cases the original author of the code is not on the team any more, or they just don’t remember why was some decision made and a piece of code written in a certain way. It might be a hack workaround for a code that was written by someone even before their time on the project. Maybe they didn’t know better at the time, or maybe they indeed made an error and now it’s my bug to fix.

Whatever the reason is, the code is written, used, and it delivers business value. It requires maintenance, fixes, and improvements and I welcome the challenges it brings.

Happy hackin’!

Tags: code, legacy, maintenance, open source.
Categories: Development, Programming, Software.

Recording screencasts of OSS contributions

by Robert Basic on April 19, 2017.

I enjoy contributing to open source projects, and I learn a lot while doing it. When someone asks me for advice on how to improve as a programmer, I usually tell them to find an open source project that interests them, and start contributing.

Easier said than done.

I’ve been contributing since… early 2009 I think, when I joined the Zend Framework mailing list.

To try and bring closer contributing to beginners, I decided to start recording screencasts of me doing open source contributions. To give a glimpse of how I do it.

So far I have created 4 of them and uploaded on YouTube. The quality is not perfect, but I think it’s good enough. There’s no video editing, I want to show how I really do it, no fixing of mistakes, no retakes. I use zoom to start a “meeting” and then share and record the screen. It’s actually the best screencasting software for Fedora I’ve found, and it’s not even a screencasting software ¯\(ツ)/¯

While doing these screencasts I also realised that I quite enjoy doing this and the whole process has the added bonus of me actual doing rubber ducking, because, well, I talk all the time as I do things.

Also, potential clients and employers can get a peak at how I work.

Happy hackin’!

Tags: about, open source, php, screencast.
Categories: Blablabla, Programming.

Contributing to open source

by Robert Basic on March 17, 2011.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Often times people ask me why do I contribute to open source, why do I “waste money and time” on free stuff when I could easily do the same thing for money? Don’t have I enough of staring at the computer at work where, well, I do the same thing - hack on code? Ummm. No.

Honestly, I don’t earn much. Enough for the rent, bills, food, but giving the fact that I don’t have a family, it’s enough for me, for now. So, I don’t make a s**t loads of money, but am still willing to work for free? Ummm. No.

Thing is, I really don’t consider this to be work. This is fun. This is hacking. This is creating stuff. This is solving problems. This is my passion. So no, I don’t work for free. I don’t work. I code, I hack.

But why open source?

Giving back

Giving back is nice. Not necessarily giving back to the same project, but just giving back to the open source community in general. It just makes you a better and nicer person :)

Knowledge

Both in high school and in college the fastest way for me to gain knowledge was to learn, collaborate with other students. Open source gives me the chance to share knowledge with hackers from all over the world; from Portugal, via Nova Scotia to Texas. It gives me the chance to be taught and to teach.

Experience

Open source gives the opportunity to work with people from every part of the globe. Getting ideas across by the means of email, chat, irc can be hard. Open source gives me the chance to improve my communication skills. Heck, I sometimes even have troubles explaining my ideas to my co-workers who sits right next to me.

Reading other peoples code, fixing bugs, writing documentation, adding new features, testing. Hack skills ++

Also, each and every accepted patch and merged pull request gives me that warm and fuzzy feeling inside.

Contacts

Open source introduces you to new people. Who knows what can come out of these random introductions? Can’t be bad, that’s for sure.

This is why I contribute to open source: it is fun, it is hacking, it is creating stuff, it is solving problems.

It is my passion.

Tags: contributing, hack, hacking, open source, random.
Categories: Blablabla.

Moblin, Linux for netbooks

by Robert Basic on May 21, 2009.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Moblin got me curios and I wanted to test it out:

Moblin is an open source project focused on building a Linux-based platform optimized for the next generation of mobile devices including Netbooks, Mobile Internet Devices, and In-vehicle infotainment systems.

Cause I don’t own (yet!) a netbook, I installed it under VirtualBox (VB from now on). The image is 666 MB big and it comes not in an .iso, but in a .img format. But, VB, a really awesome software, had no troubles booting from it. As with the majority of Linux distros nowadays, Moblin image is also a Live CD, which means you can run it, without installing it.

The preinstall process is made up from 6-7 steps: choosing the language, the keyboard layout, the timezone and, of course, the partitioning. Basically, it’s just another boring “Next-Next” process. The installation itself took around 6 minutes to finish. When it’s done, it asks for a username and a password.

The first boot went pretty quickly, considering that booting under VB takes longer than booting under regular installations. The thing about VB is that it needs, the so called “Guest Additions” installed on the guest machine, so that the guest machine can be used normally. In this case, I failed to install it: Moblin comes with one version of the Linux kernel and the additions are for another version of the kernel. This prevented me in my quest to test Moblin fully. Anyway, I’ve managed to take a few screenshots of it, all are uploaded to my Picasa profile.

There was one thing that was strange. It has a “Status panel”, from which you can update your profiles on social networks. A really useful stuff. I just opened it up and updated my Twitter profile. Almost. I wasn’t logged in to Twitter from it and Moblin didn’t say a word about it. It just happily said that my status is updated. Once I found the “Web services” panel I logged in and this time I was really updating my Twitter stream.

I really was hoping to test it normally and write a detailed review of it, but this guest additions thingy thought otherwise. Moblin is a great distro, even in this beta stage I believe it’s useful. What do you think? Did you test it already, saw it in action?

One thing’s for sure: when I’ll get myself a netbook, it’ll run on Moblin.

Cheers!

P.S.: Check out the Moblin intro, too!

Tags: about, introduction, linux, moblin, netbook, open source, random.
Categories: Blablabla, Free time, Software.