GSOC 2013/Student Application Islamgulov/Blocker Bug Tracking

Proposal Description

The proposal is based on a Fedora GSoC 2013 idea by Tim Flink.

An overview of your proposal

Fedora Blocker Bug Tracking is web application that was designed to track release blocking bugs and related updates in Fedora releases currently under development. As the warnings state, it is currently in a state of heavy development. I am willing to implement new features, which will be helpful for Fedora QA.

The need you believe it fulfills

While the app itself already exists, there are many features which would be nice to implement. The needs of this proposal fulfills to provide features which required by community.

Any relevant experience you have

I'm passionate about technologies in general. I consider myself as an experienced Python developer. I am comfortable with the Python philosophy and I have created a bunch of application in Python. I'm familiar with revision control system, continues integration tools and web technologies. I have experience with libraries which used in Blocker Bug Tracking before, such Flask, SQLAlchemy and others and creating RESTful APIs.

How you intend to implement your proposal

First I think I need to get familiar with the the domain, such as - what is blocker bug - what is a freeze exception? - what is an update? how is it different from an NVR - what does QA use test images and spins for? - what is the difference between stable and updates-testing At last close some tickets. This things must be completed before official start. The proposal suggest to provide some new features which described in timetable.

A rough timeline for your progress

May 27 - June 17

Examine codebase, bond with the community better and plan out finer details of the project, get familiar with domain.

June 18- July 28

Start coding for the project. Implement tasks: 1 week: create unit tests for html template render 2, 3 week: improve update syncs

• use new query features for bodhi

4, 5 week: RESTful API for existing concepts

• existing blocker/fe bugs
• updates in need of testing

6, 7 week:extend existing spin tracking

• request spin via html or api
• get spin contents (updates) via api
• write a script that translates updates into NVRs
• allow updating of a spin with location and state via API & auth

June 29 - September 15

1 week: filters in frontend

• initial research, reviewing pages

2 week: fix the admin interface 3 week: filters in frontend

• implement pages with filters according community feedback

4 week: search functionality

• by title and bug id in first approach

5 week: integration with Fedora Infrastructure Message Bus

• discuss with fedmsg team and integration

6 week: email integration

• send out a daily “blocker update”

7 week: cleanup code and functionality

September 16 - September 23

Final documentation. More testing. Usage examples.

Optional tasks, nice to have, but not critical for GSoC project

This optional tasks would be implemented in accordance to the time left after completing all the mandatory tasks: - extend CI tests with deployment - migrate css to foundation 4

Any other details you feel we should consider

Now I’m working on my thesis in university, I will defend it at the end of June. I assure dedication of at least 40 hours per week to the work and that I do not have any other obligations from late May to September.

Have you communicated with a potential mentor? If so, who?

Yes, I've communicated with Tim Flink