Contact Information
Email Address: blaskovic.branislav@gmail.com Telephone: 00420 608 635 498 Blog URL: https://github.com/blaskovic/homepage/wiki Freenode IRC Nick: Brano
Fedora Gooey Karma - GUI for CLI tool
I really like the idea of Karma system for bug fixes. I think, lot of people are not using it because they don't know about the CLI tool or it's not so "handy" for them. This GUI tool should be the best solution to get people involved in this process.
This tool should make adding karma and testing easier. Timothy Flink wrote some lines about the tool on his blog. Then mkrizek created some mockups with PySide. I would like to continue on this work and discuss it regularly with tflink, mkrizek and jskladan (as a new mentor).
The need you believe it fulfills
I believe, more people will prefer GUI tool over easy-karma. Easy karma is not bad but GUI tool provides more space to bring user more information about update, than it's possible to do just in terminal.
Although there are Update feedback Guidelines, many of people give negative karma in the "wrong" situations, e.g. when the update is not working perfectly (fixes all but one of the bugs), or when the update brings a new minor bug, but the other changes from the update improve the updated program significantly . This tool should inform the users to be 100 per cent sure they really hit the bug which that build should have fixed. Fedora-easy-karma "forces" people to leave comment/karma for all of the updates, because they are comming one after another. Sometimes it's better to skip the update if we are not sure what and how to test it, and by allowing the users to either "blacklist" some packages, and/or highlight those with better probability of being tested by the user (e.g. tested in the past, of updates for the software he/she is using on his computer), the GUI tool should bring Fedora more relevant results/responds from the current users, and could allow for new users to start making Fedora better with ease.
Any relevant experience you have
This project will be in python and qt. I am maintainer of MoinMoin wiki and I wrote several projects in python. I've worked with QT in C++. Network communication over XMLRPC and HTML (webpage) parsing are my hobbies - I wrote some Facebook notification parsers, some poll voting scripts and others :)
What should this tool do (How you intend to implement your proposal) ?
- List of bugs which the update fixes
- List of installed/available packages from testing repositories
- Browser of not-installed but available updates
- Filters/Highlights - if user is running firefox at the moment, recommend to test it
- Maybe use the "most-used" apps from gnome-shell?
- Or get packages which user tested before
- If there are some Test Cases in Bodhi, show them for easier testing
- Highlight comments with negative karma - maybe somebody else had the same issues
- Show package description from yum
- Dependency tree - that would be great to have - you never know what breaks the thing :)
- Try to hint the "end/desktop" applications for libraries
- For example - if libpurple is fixed, provide user with information like "libpurple is used by Pidgin, if Pidgin works as expected, libpurple is probably also working"
- Hints for deciding the right karma
- Checkboxes with some questions related to the testing process and the Update Feedback Guidelines
- Once the user inputs the answers, suggested karma will be shown
- Maybe option to download patch (or SRPM) directly would be great!
- Ignore updates which were commented by current user, but on another PC
- Recommend updates which got bad karma
- It would be great to retest them by another user
- Favourited and ignored packages
Tim has perfect picture of GUI and I hope I can show link to it from here.
Time plan
- 1st - 2nd week
- Discussions with mentor to sum up the details.
- 3rd - 4th week
- The skeleton of application - it's important to do perfect base for easier works with additional features.
- 5th - 10th week
- Adding features according to plan.
- 11th - 12th week
- Discussions with mentor and final edits.
And why choose me over other participants? I don't think I am the best of the best but I know how it's going in Fedora and Red Hat. Josef Skladanka (mentor) is working in Brno office too, so the discussions could be in real life and not only via IRC/Jabber. :) I am working with python every day - I am maintainer of MoinMoin wiki in Red Hat which is wrote in Python.
There are some answers to questions from Google Melange
- Why do you want to work with the Fedora Project?
- Because I would like to participate on Fedora. I was testing Fedora 17 before release. I were participating on Power Management test day of F19 as well. Now I am dogfooding F19. Fedora is my favourite operating system which I run on several PC/laptops and my own server. I really like the idea of cooperation between developers and users. This tool should be the easiest way to get regular users involved in Fedora development.
- Do you have any past involvement with the Fedora project or another open source project as a contributor?
- I am working in Red Hat Brno office as QA for RHEL. I've found some bugs and most of them were fixed and then verified by me. Sometimes I proposed patch to fix found bug.
- Did you participate with the past GSoC programs, if so which years, which organizations?
- No, I did not.
- Will you continue contributing/ supporting the Fedora project after the GSoC 2013 program, if yes, which team(s), you are interested with?
- Of course I will :)Dogfooding new releases and finding bugs is very satisfying to me. I hope I could continue contributing this project after GSOC and I will try to improve it with cooperation with Fedora QA guys. This tool should not stay in one place because there is a lot of space how to make testing easier for users.
- Why should we choose you over other applicants?
- I don't think I am the best of the best but I know how it's going in Fedora and Red Hat. Josef Skladanka (mentor) is working in Brno office too, so the discussions could be in real life and not only via IRC/Jabber. :) I am working with python every day - I am maintainer of MoinMoin wiki in Red Hat which is wrote in Python.
- Have you communicated with a potential mentor? If so, who?
- I've talked to Timothy Flink, Josef Skladanka and Kamil Paral.
Recommendation from my team leader Ales Zelinka
Dear all,
Branislav works under my supervision since February 2012. He is efficient, goal oriented and can solve problems individually. He successfully finishes all assigned QE tasks and takes on additional responsibilities and challenges. For example he manages and improves our wiki instance and co-develops our test automation framework reporting (both implemented in Python).
In summary, I believe Branislav is a very good candidate for Google Summer of Code 2013. Please feel free to contact me if you'd like any additional information.
Ales Zelinka Red Hat Quality Engineering