Over the line

GSoC-2014 isitfedoraruby - Week 1

~6 min read in opensource

In case you haven't heard, I have been accepted again this year for Google Summer of Code :) This time I will be working on enhancing a Rails app that provides information about the state of rubygem packaging in Fedora.

isitfedoraruby is a project that was crafted in GSoC 2012 by Zuhao Wan. I will pick it where he left off and add some new features that will hopefully make us packagers' life easier.

You can read my proposal here.

Why I got involved in this project

Last year was the first time I took part in GSoC, first time I got involved in Fedora, first time I started contributing to GitLab. I am now a packager, still trying to package GitLab for Fedora/RHEL (help needed!) and a member of GitLab's community core-team. I even became an apprentice to Fedora's infra team (although I haven't dedicated much time admittedly).

So, having packaged a bunch of rubygems already, I have stumbled upon many cases where my packager's life would be easier if I had some tools to work with. And this is where isitfedoraruby comes in. As a rails app, it looked like the perfect opportunity to learn about the framework and make something that the Fedora Ruby community could use on a daily basis when packaging.

Project details

As I wrote earlier isitfedoraruby is a rails app used mostly internally in Fedora by ruby packagers. The source code is hosted on github, deployed on Openshift and all the info is imported using a rake task using a cron job every hour.

What you see in production is using Rails 3 and ruby 1.9.3. Zuhao has already worked in porting it to Rails 4 so I'll be working on that branch.

The same project was also picked by some high school students during Google's Code In program in 2012. You can read more in Mo Morsi's blog post.

What we have so far

Here is a brief list of the pages there are so far.

General info pages

  • Home page
  • All rubygems
  • All fedorarpms
  • Contribute
  • About
  • Gemfile Tool

Single rubygem page

  • Link to fedorarpm
  • Homepage url
  • Source code url
  • Version
  • Total downloads
  • Description
  • Dependencies

Singe fedorarpm page

  • Header links
    • Dependency Tree (using D3 js library)
    • Timeline (chronological visualization of the bugs & version releases)
  • Link to rubygem
  • Link to source code url on https://pkgs.fedoraproject.org/cgit
  • Number of git commits
  • Up to date (yes/no)
  • Link to maintainer
    • link_to bubble chart page showing the packages a user owns
    • Table of rpms owned by user
      • link_to rpm
      • Upstream version
      • Rawhide version
      • Number of git commits
  • Description
  • Versions table
    • rawhide
    • fedora 20
    • fedora 19
    • gem version
  • Dependencies table
    • package name (link_to fedorarpm)
    • rawhide version
    • f20 version
    • f19 version
    • upstream version
  • Dependents table
    • package name (link_to fedorarpm)
    • rawhide version
    • f20 version
    • f19 version
    • upstream version
  • Bugs table
    • ID (link_to bugzilla, striked if resolved)
    • Bug title
    • Review status
  • Builds table
    • Build ID (link_to koji url)
    • title (package name)

Features to be added and bugs fixed

Test suite

The current test suite is non-existent. Some of the tools I plan to use are:

  • rspec for testing models and controllers
  • factory_girl for feeding tests
  • capybara to simulate user interaction with the app

For views I will use feature specs. Existing minitest tests will be replaced with rspec ones.

Enhance the gemfile tool

The Gemfile tool checks against a Gemfile or Gemfile.lock and shows if the gems are packaged for Fedora. In its current implementation, it basically dumps all the information in the screen, which is not too handy if you need to somehow extract this information.

The functionality I want to add is:

  • provide a better view of the output (prettier table view)
  • ability to provide a Gemfile url and have the output on a static page like: https://isitfedoraruby/stats/gemfile?url=www.example.com/Gemfile.lock

With this we could calculate how many of the gems are in Fedora repos, which brings me to another cool feature.

Show the packaging progress of a gem

There are times where a gem depends on other gems not yet packaged for Fedora. A cool feature would be to able to see the packaging progress of a gem.

The plan is to either implement one of the two options below (or both):

  1. Query https://rubygems.org and extract information on the dependencies.
  2. Provide a yaml file with info on the gem's review request bugzilla issue, then query koji for rawhide builds and bugzilla for any Blocks issues. If we have those two values we can calculate how many dependents gems there are not yet or already packaged.

I prefer the first option as with that one could see what dependencies needed prior to submitting a package for a review request.

A nice progress bar with the percentage of gem packaging completion will be provided as well. For each gem that gets in rawhide, the progress bar gets a little further. There can also be a number of other cool info in the page, like links to bugzilla requests so that someone could lend a hand, etc.

At first I will focus on implementing this for a single gem but later it can be extended to track the progress of a rails app.

That functionality will mainly come from the next feature in the list. Enter dependency checker.

Enhance dependency checker

The current representation of a gem's dependencies is in a tree format, not very handy if you want to extract information.

Influenced by https://www.gemlou.pe, I plan to implement a similar representation and show the dependencies in a more elaborate way.

UI/UX enhancements

The app uses bootstrap as a frontend framework, as you could tell. The idea is to make it more user friendly and prettier. If it were me I would have used foundation in the first place. Upstream provides even a gem for immediate use in rails apps. In my opinion it's targeting more to developers that don't want to get too messy with css. For the time being I don't consider changing frameworks, but it's a food for thought.

Add pages providing more general info

Pages that would help the user experience are:

  • list of gems pending review
  • list of gems already assigned but stagnated for too long
  • list of gems pending review and marked as NEEDSPONSOR

All these can be queried from bugzilla through the ruby-bugzilla gem.

Documentation on contributing

Last but certainly not least, I will document the development contribution process should anyone want to provide any fixes/features.

Apart from developing the app, I will provide a page with comprehensive steps on packaging a rubygem. A draft article can be found here.

Progress of previous week

I have been reading the codebase to get familiar with it and then done a few minor things.

Deploy on staging server

Currently I run it on heroku, but the database exceeded the free plan they provide so I'll have to move it elsewhere. I haven't yet imported the gems as the rake tasks pull in all gems from rubygems.org and the database gets huge. This is noted to be fixed in the rake task. Also, what you see is the next version of the app using Rails 4 :)

Note bugs that need fixing

Like last year, I will be documenting any progress in a trello board. In the code clean up list you can see what is marked as to be fixed. If you have any comments please do leave them on the cards.

What's on this week

We are already in the middle of the second week, so here's a preview of what I'm working on.

Architecture analysis

The code needs a clean up and the only way to do this is to do an analysis of the app's architecture. That will give me an overview of the changes need to be done like merging the rubygem page view into fedorarpm.

Setup a proper dev/test environment

Right now, if anyone wanted to play with the app, apart from db migration you would have to run the rake tasks that import all the info needed in order to have a functional app. Rather than importing each gem (which can be done in batches), I would like to create some fake data to begin with.

This would help me afterwards with the tests.

Fix bugs found in first week

I'll try to apply fixes to as many bugs as possible I found previous week.

The end (for now)

Soo, that's it for now! Hope you made it this far :) Cheers to an interesting summer!