From Fedora Project Wiki

This is a WIP and not ready for the public yet ;)

About me

  1. What is your name?
    • Ionuț Arțăriși
  2. What is your email address?
    • mapleoin@fedoraproject.org
  3. What is your wiki username?
  4. What is your IRC nickname?
    • maploin
  5. What is your primary language? (We have mentors who may speak your preferred languages and can match you with one of them if you request.)
    • Romanian. English is fine, thank you.
  6. Where are you located, and what hours do you tend to work? (We also try to match mentors by general time zone if possible.)
    • Romania. My working hours vary a lot. Anytime between 6AM and 12PM GMT.
  7. Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?
  8. Bonus level: What's your schedule and why?
    • I'm a terminal year college student in Romania where school officially ends in July. Since this is also the year when I have to write my thesis I'd like to deviate from the standard Summer Coding schedule. My first term will be the standard second term and I'll add another term starting from the standard midterm evaluation date. I'm aligning with a few standard dates to try and keep things as simple as possible for others. I can and will probably start working a bit earlier. So it would look like this (11 weeks in total):
      1. First term - 12 July - 16 August (my midterm evaluation date)
      2. Second term - 17 August - 27 September (student final report etc.)

Interactive SPEC pages

Description

  1. Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?

Timeline

SPEC indexing/searching

  1. (.5 weeks) write the database schema to support adding specfiles to pkgdb. Decide on a standard number of attributes that will match the specfile sections.
  2. (1 week) write a script to crawl all the cvs specfiles we currently have and get them in the db. Write a cvs post-commit hook to update the pkgdb when a new change is made to a spec file. Q: should we prepare for git? I think so -- need to talk to jkeating to see about timeframe but I think it's F14/15 material so we want to be ready. Also: we want to make sure hooks don't take so long to run that they interfere with maintainer workflow.
  3. (1 week) Implement full-text search on the specfiles that can output line numbers. (maybe go back to 1. to put line numbers into the db?)
  4. (.5weeks) Write WebUI for search.

SPEC web page

  1. (1 week) write the UI to have all of the different sections from the db united to form the original SPEC file with nice coloring (syntax highlighting?) and line numbers.
  2. (.5week) Database schema for specfile-comments (tie comment to line-number)
  3. (1 week) Write WebUI for commenting on specfiles
  4. (1.5 weeks) Integration with bugzilla - comments opened (by a privileged group like 'packager' or should the privileged group be the only ones allowed to comment?) should open a bugzilla ticket, and closed tickets should color the comment gray and make it unwriteable (make a new one or reopen).

Package Review

  1. (.5weeks) find a way to store comments/specfiles etc. for packages we don't have in the db yet (build a new not-yet-packaged table?)
  2. (1 week) Make a list of MUST items in the database with links to the actual guideline paragraph, make each comment a possible link to one of the guidelines. (Q: Is there a way to guarantee that the pkgdb MUSTs and guideline links are updated every time the wiki pages are updated?)
  3. (2 weeks) Make a list of MUST items somewhere on the SPEC page if the package is not yet in the pkgdb that can get checked individually by different reviewers. (Build db schema to allow tracking of responsibility for checked items? who checked what)

Total: 10.5 weeks

Convincing

I've been a Fedora Project contributor since May 2008 when I began working on the Fedora PackageDB with Toshio Kuratomi. I worked on small features, visible to the general Fedora user. One of the features I'm most proud of that I worked on in that period was an advanced package search functionality.

Last summer I participated in GSOC working on a bunch of features for the pkgdb aimed at making it more user-centric, rather than developer-centric. These included importing metadata from yum, a new package page with commenting and tags and exporting those tags for future use in yum via sqlite. This work was later adapted and included into the 0.5.x series of the PackageDB after some design changes to PackageDB itself.

At the end of the summer I began contributing to the Fedora Project as a Package Maintainer and have contributed this way since then. I've also begun a personal project of a Romanian FOSS advertising network. More info on the project on its webpage (Romanian) or on github (code).

Me and the community

Impact

If your project is successfully completed, what will its impact be on the Fedora community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Fedora community, at least one of whom should be a Fedora Summer Coding mentor. Provide email contact information for non-Summer Coding mentors.

Ionuț's answer

The Fedora community will have an improved way of handling package reviewing. Since Packaging is a fundamental part of the Fedora Project and the package review process is the most important way through which packages get accepted in Fedora, the impact will be high. Though only immediately visible by the Fedora developers, this project ultimately aims at improving the general quality of Fedora packages by making it easier for developers to review each other's work before and after the package has been accepted in the official repositories.

answer 2

answer 3

  1. What will you do if you get stuck on your project and your mentor isn't around?
    • I generally find my way out of most technical problems by googling, going deeper into the source code or just asking on the relevant IRC channel (#turbogears, #python, #yum etc.)
    • For design problems, though these are less likely to happen, I know my way around the community mailing lists and IRC channels and generally know who's who. If my mentor will be missing for several days I'll probably start asking for advice on #fedora-admin and #fedora-devel.
  2. In addition to the required blogging minimum of twice per week, how do you propose to keep the community informed of your progress and any problems or questions you might have over the course of the project?
    • I'm constantly lurking on IRC in #fedora-devel and #fedora-admin and am also subscribed to the relevant mailing lists.

Miscellaneous

  1. We want to make sure that you are prepared before the project starts
    • Can you set up an appropriate development environment?
      • sure
    • Have you met your proposed mentor and members of the associated community?
      • Yes, I've worked with my mentor before and have been part of the Fedora community for 2 years.
  2. What is your t-shirt size?
    • M
  3. Describe a great learning experience you had as a child.
  4. Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?

Note: you will post this application on the wiki in the category Category:Summer Coding 2010 applications. We encourage you to browse this category and comment on the talk page of other applications. Also, others' comments and your responses on the talk page of your own application are viewed favorably, and, while we don't like repetitive spam, we welcome honest questions and discussion of your project idea on the mailing list and/or IRC.

The NeL project has some good general recommendations for writing proposals. We encourage Summer Coding code to include tests.