I really had to laugh when starting this reading—bugs was a poignant topic after working on the Freeciv problem earlier in the week—not for what the assignment was about, but for what it caused. Other members of my group had a worse experience in terms of the damage it inflicted on their machines so I really should not complain. Evidently Freeciv must have changed some dependencies or settings because some of the functions of our build that were working—now were broken. So the most important lesson that I learned from this experience, was to create a quarantine box for any work that is due outside the purview of our project…no sense in adding work that I’ve previously completed to an already hectic schedule!
Back to the bugs….well the second part of our assignment (finding out how to set up a bug-tracker account) was extremely easy—thanks to Sugar Lab’s well organized wiki. It was prominently displayed on their wiki—which only asked for me to create a username/password and to provide an email address in case I ever needed to reset the password. This new “access” didn’t really change what I saw before, but presented it differently. It showed where bugs had been assigned (without having to delve into the ticket) and ordered the tickets a little differently.
The first part of our assignment was to find the oldest bug that Sugar Labs has; well there are actually 3 of them at 2 years (no specific date given on the ticket only a general time frame) and all of these 3 are actually more of “enhancements” than bugs; for example, ticket #405 “Insufficient feedback on pressing of Keep button in non-optimal viewing conditions.” This is only relevant to certain types of monitors (XO and SoaS with LCD screens) where a bit of a glare can cause the user to inadvertently hit the wrong button causing their harm to the project they were working on. Bug #405 is one of the few tickets that do not have a lot of feedback posted and I think it just isn’t a priority. I would assume with this only affecting a very limited number of monitors that it is hardly worth the effort to explore—(and to reproduce the “bug” one would have to have the specific type of monitor) which are two reasons I would give as to why it has been around for 2 years.
Recreating a bug (the third part of our assignment) was the easiest of all. Bug ticket #1997 states that “Read fails to start if Hal is not installed.” I know for a fact that all my dependencies have been installed and Sugar Labs source code was successfully built on my box. When I attempt to open “Read” it flashes then gives the message “Read failed to start.” I read a little more in the ticket (updated 19 hours ago) that a patch for this problem has been created, but is waiting on approval from the activity maintainer before it can be integrated. Hmm…a long approval process maybe?
The last part of the assignment is to work on triaging 5 new bugs. After reading what goes into triaging, it would be too simple to take those from Sugar Lab’s site…they appear to already be organized and defined well beyond my abilities. I went to the links for GNOME, Fedora and Ubuntu and think that’ll be where I start. In fact since my disdain for Ubuntu is growing daily, I’ll make an account there and see how that turns out—there should be PLENTY of bugs for this OS. I’ll work on that tomorrow…after at least a couple of hours sleep!
No comments:
Post a Comment