Sunday, June 25, 2017

After adding a checkbox to the test report form to differentiate staging releases from the development branch went fairly smoothly, I decided to take a stab at a longstanding and (for AppDB admins) very annoying bug: new distributions are added to the database even if the admin rejects them.

The test report form users fill out has a dropdown list from which they can select their operating system (though it's labeled "Distribution," which is in itself a problem since we also have MacOS and *BSD users). There is also an input box for users to add their operating system/distribution if they don't find it on the list, and that's where the problem starts. Some users don't search very carefully and enter distros that are already on the list, while others misunderstand the Distribution label completely and try to enter the name of the developer, distributor, or the application version.

Whatever the mistake, maintainers and admins are supposed to be able to correct it when processing test reports, and that's what's not working. The person processing the queued form can delete the added distribution from the input box and select one from the dropdown list, but that change is ignored when the test report is approved and the invalid distro is added to the database, with the test report still attached to it.

So I spent the past week and a half beating my head against the wall trying to figure out why this is happening. Much of that was focused on comparing the code for submitting new distributions to the code for submitting new vendors, which has the same UI but is working properly. I  tried changing parts of the distribution code to mimic the way it was done in t he vendor code. Changing the way the dropdown list is generated made a partial difference, and I do have a patch that enables the test report to be submitted with the changed information. Unfortunately, the incorrect distro is still added to the database (albeit with zero tests attached, so it's easier to clean up) so I know it's not completely correct.

At that point I decided to take a step back and work on something else for awhile. Not giving up; I'll come back to it with fresh eyes and a bit more experience.

On the plus side, the first thing I turned my attention to was another old bug turned out to be simply a typo in a URL.

Saturday, June 10, 2017


I come into this internship with an extensive knowledge of Wine and the AppDB as a user (9 years) and little in the way of technical skills. What I know is what I've picked up over the years as a Linux user, which, granted, is much more than what I would have learned had I stayed with Windows.

But in terms of what's needed to wrestle with the AppDB code, it's not much: basic html and css, an understanding of how relational databases work from a job years ago where I had to run queries using a now-defunct language on an IBM mainframe, and (thanks to having run regression tests on Wine) how to use git. I had no training or experience in Apache, MySQL, PHP, Javascript, JQuery, or Bootstrap prior to being accepted as an intern.

I spent the month leading up to the official start of the internship setting up a local test environment, and with the help of a mentor who's been very patient with my newbie questions, getting better at troubleshooting Apache and PHP errors.

The learning curve so far has been about what I expected. MySQL has been the easiest because I do understand how database queries work and just have to look up the specific MySQL syntax for what I want to do. PHP has been the hardest, in part because the AppDB code is poorly organized and difficult to follow even for someone who knows PHP. 

I have nonetheless managed to fix some small bugs, and learned a few things. I expect the learning curve to get steeper before it gets easier.















Friday, May 5, 2017

Blog created to record entries for my Outreachy internship with the Wine Project, May-August, 2017.