This bugs me

This post will be mostly focused on reflecting upon Chapter 6 of Teaching Open Source with quick updates about my team's work on Galaxy throughout.

Teaching Open Source: Chapter 6
The chapter is entitled "Debugging_the_Code". This segues perfectly into what, as a team, we are doing with Galaxy. The chapter starts by talking about how, pretty much, anyone can look at bugs in a FOSS project and how anyone can contribute to the fixing of these bugs. The chapter quotes Eric S. Raymond in saying "...with enough eyes, all bugs are shallow." This quote epitomizes the beauty of open source projects and, thusly, disintegrates the idea of "the mythical man-month" that I talked about in one of my first blogs. With hundreds (or even thousands) of motivated developers looking at a project, then bugs can become more obvious to find, more obvious to solve, and more obvious to patch up. More is better; with open source, no one is just working for a paycheck. Developers are working for the betterment of the project. Even if someone is doing it just as a resume padder, they are still contributing meaningful work rather than slacking off at their desk browsing Reddit or checking their Fantasy sports scores.

Next, the chapter delves into bug trackers. This was a concept completely foreign to me until recently. Galaxy uses Trello as their bug tracking software. Effectively, a bug tracker is a piece of software where members of a FOSS project can report bugs about a project. These reports typically contain specific pieces of information (adapted from TOS):
Summary - A short description of the bug-at-hand.
Description - A detailed description of the bug. Typically explains how to reproduce the bug and what results were expected versus what actually happened.
Comments - This allows other developers to comment and say "Yeah, this happens to me as well" or where someone can point others to documentation - maybe the bug is actually a feature.
Reporter - Whom reported the bug.
Owner - Whom is assigned to fix the bug
Version - Bugs can be very version-dependent so version is important.
Severity/Priority - Priority is what bug is going to get fixed first (think of a priority queue). Severity is set by the user that reported the bug.
Status - Bugs can be new (unassigned), assigned, or closed (patched).
Resolution - This only impacts closed bugs. Fixed means that the bug was fixed. Nextrelease means that the bug is fixed, but will have the patch pushed out with the next release (or version) of the software. Bugs that are the result of users misusing the software or misinterpreting something is flagged as invalid or notabug. Lastly, some bugs are just not worth the developers' time to try and fix and these are flagged as wontfix.

Next, the chapter just talks about the benefits of having all of this information about bugs. A developer can open up a bugtracker and essentially ask "Alright, what is new and broken?" or "What needs to be done ASAP?" This can all be done by just filtering specific information. For finding new and broken things a developer could search for every bug with a new status and for finding what needs to be done ASAP a developer could search for every bug with a high severity or high priority.

Upon reading all of this, I realized that my team and I had not been assigned to the bug that we want to fix. So I quickly hopped on to the Galaxy IRC and posed my current issue of not being assigned. A screenshot of the IRC chat can be found below.
So I had to go and look up, specifically, what a pull request is. From GitHub, I was able to learn that pull requests are a way to tell others about changes you've pushed up to a repository. After sending a pull request, others (The Galaxy devs) can review the changes, talk about things that should change if needbe, and then push up follow-up commits. Essentially, it is a formal way to add your changes to the master, or developer, branch.

The next section of TOS: Chapter 6 asks to go and find the oldest, unpatched bug through the open source project's bugtracker. Unfortunately, Trello does not currently support sorting bugs or requests by date. When trying to find older bugs, I went through and tried to find bugs that were overdue or not critical (as those may have fell to the backburner quickly), but none of it really helped. Trello is pretty much perfect for filtering and sorting by any other manner, though (such as severity, priority, etc.).

Proceeding this, TOS: Chapter 6 asks the reader to create a new account on the bug tracker for the open source project. Funny enough, I created my account for Trello about a week ago and I just furnished my profile during this blog post in order to post onto the Trello card (way of representing a bug) for the bug that we initially decided to try and fix.

Penultimately, TOS: Chapter 6 suggests trying to reproduce a bug with an open source project. Naturally, again, I chose Galaxy. Most bug reports on Galaxy tend to not specify a specific version for which the bug occurs. It almost seems like it is expected of people to use the latest version. Sometimes there is a specification of the backend (when it is relevant) that is managing the database for Galaxy as people can use their own instances of databases (for example, with Learn2Mine we utilized our own postgreSQL backend). The bug I reproduced was as follows:
Trello link
Summary - Bug when using data_column
Description - Dear galaxy developers,

When using the data_column type for a tool in galaxy, there is a bug that gives the message "An invalid option was selected, please verify". The problem occurs when for example you had selected a dataset with 6 columns in it and selected as a choice the 6th column and then changed your mind and selected another dataset with 5 columns. This happens because when it checks in basic.py if the value selected is in the accepted values of the selection list, the value it uses is the one that was selected on the previous dataset. A simple solution would be to not do this test when a new dataset is selected, or reset the value of the selected item when a new dataset is selected.

Regards,
Aris

Comments - One person added the card to their inbox (to follow it)
Reporter - Aris (Non-registered Trello user)
Owner - None currently
Version - Not specified (assumed latest stable build)
Severity/Priority - Low priority and severity
Status - There is no specification on Trello, but it fits the description of new
Resolution - None yet.

Lastly, in my last blog post I mentioned that I would circle back and talk about the timeline after group consultation. We have an updated timeline on our wiki now and it looks as follows:

Music listened to while blogging: Kendrick Lamar and Cashmere Cat