Week 1 and 2 Status

Progress

The semester has officially started and we put our noses to the grindstone. There’s a lot of work to be done, but we all worked very hard this week to do as much as possible. We made progress with our code base in security adjacencies, NLP, ownership, and interactive churn.

Alvaro was able to finish the code for security adjacencies save for a bug he’s in the process of fixing. He’s also started looking into defining and finding the major and minor contributors of Chromium.

Brian worked on NLP, this week, as he does every week. This week he focused on speeding up his code, as it’s been taking a while to run. He made performance improvements on vocab loading.

Richard made progress with ownership. This week he was able to fix the failing verifies for first ownership and got the first ownership data loaded into a table.

I’ve been in charge of gathering interactive churn data, as we need it for some of our metrics.

The Adventures of Interactive Churn and its not so trusty friend, Git Blame

I’ve spent time in the past week or so porting over a git-interaction-churn script from a past project that gathered developer activity metrics. We want to make a gem out of this eventually, so I spent some of my time figuring out how Ruby Gem development worked. I ported over the script and started to make it work for us. My version of the script runs without needing a bash script to gather the commit history. I also made it so the gathered interactive churn data was dumped to a CSV file, instead of just plain text.

I started running my interactive churn script to gather data. I was expecting, based on knowing how fast it ran in the past on other code bases, that my script would finish gathering churn data in a few days at the most. I soon realized that I was wrong. The script from what Professor Meneely and I calculated would take nearly 60 days to run, which we can’t reasonable handle. To try to fix this problem, I narrowed the scope of what git blame had to look at, but that didn’t help the scripts performance enough.

I’ll be handing this script off to someone else soon, but before I do that I am going to look into ways to speed up the script. I’m going to look into implementing Rugged to speed it up. I think it might end up being faster if I don’t shell out in my Ruby script.

This project is sponsored by the Collaborative Research Experiences for Undergraduates, funded by the National Science Foundation.