From Fedora Project Wiki
(Remove duplicate)
(Better headings)
Line 1: Line 1:
=Proposal=
[http://isitfedoraruby.com isitfedoraruby.com] is a web-application built with Ruby on Rails, that keeps track of the Fedora/Ruby integration, especially gem -> rpm conversion.
[http://isitfedoraruby.com isitfedoraruby.com] is a web-application built with Ruby on Rails, that keeps track of the Fedora/Ruby integration, especially gem -> rpm conversion.


The project was started on 2012 as a Google Summer Of Code project by [[User:Zuhao]] and later were added some new [http://mo.morsi.org/blog/node/378 features] during the Google Code In program. This is my idea of enhancing it from a packager's point of view.
The project was started on 2012 as a Google Summer Of Code project by [[User:Zuhao]] and later were added some new [http://mo.morsi.org/blog/node/378 features] during the Google Code In program. This is my idea of enhancing it from a packager's point of view.


==An overview of your proposal==
=An overview of your proposal=


isitfedoraduby is a nice project that never got the attention it deserved. I believe this is because it serves merely as a portal of the gems packaged for Fedora, showing their statuses and some nice statistics and graphs.  
isitfedoraduby is a nice project that never got the attention it deserved. I believe this is because it serves merely as a portal of the gems packaged for Fedora, showing their statuses and some nice statistics and graphs.  
Line 25: Line 23:
I will try to expand below each item.
I will try to expand below each item.


==The need you believe it fulfills==
=The need you believe it fulfills=


These enhancements will hopefully promote the site usage among Fedora ruby packagers and attract new ones.  
These enhancements will hopefully promote the site usage among Fedora ruby packagers and attract new ones.  


===For new packagers===
==For new packagers==


Based on my experience as a new rubygem packager a year ago, I have compiled some useful information for the packaging process that would help new users to engage in ruby packaging much quicker than I did. You can read a draft [https://github.com/axilleas/axilleas.github.io/blob/source/src/drafts/fedora-rubygem-packaging.md here]. This will be accessed through a special docs page on isitfedoraruby.com and could be edited with pull requests in the github repo.
Based on my experience as a new rubygem packager a year ago, I have compiled some useful information for the packaging process that would help new users to engage in ruby packaging much quicker than I did. You can read a draft [https://github.com/axilleas/axilleas.github.io/blob/source/src/drafts/fedora-rubygem-packaging.md here]. This will be accessed through a special docs page on isitfedoraruby.com and could be edited with pull requests in the github repo.
Line 37: Line 35:
Of course documentation is not the only important thing, new packagers could also use the advanced features I describe below.
Of course documentation is not the only important thing, new packagers could also use the advanced features I describe below.


===For existing packagers===
==For existing packagers==


The new enhancement that I have in mind for the gemfile_tool will help packagers that want to package an application with many dependencies. For example, Gitorious and GitLab are two big rails projects with over 100 dependencies each. The way gemfile_tool is now implemented isn't of much use. Using the polisher gem we can enhance it to depict the dependencies in a nice format (table maybe), export to json, display only the runtime dependencies, etc.
The new enhancement that I have in mind for the gemfile_tool will help packagers that want to package an application with many dependencies. For example, Gitorious and GitLab are two big rails projects with over 100 dependencies each. The way gemfile_tool is now implemented isn't of much use. Using the polisher gem we can enhance it to depict the dependencies in a nice format (table maybe), export to json, display only the runtime dependencies, etc.


==Any relevant experience you have==
=Any relevant experience you have=




==How you intend to implement your proposal==
=How you intend to implement your proposal=


===Refactor basecode where needed===
==Refactor basecode where needed==




===Write rspec tests===
==Write rspec tests==


Currently we have almost none.
Currently we have almost none.


===Enhance gemfile_tool===
==Enhance gemfile_tool==


That would be really awesome as it would really
That would be really awesome as it would really
Line 65: Line 63:
like the one I create here [2]. And the list goes on  
like the one I create here [2]. And the list goes on  


===Packaging progress of a rails app or a gem===
==Packaging progress of a rails app or a gem==


Separate page that describes the packaging progress of a gem with many
Separate page that describes the packaging progress of a gem with many
Line 78: Line 76:




===Enhance dependency checker===
==Enhance dependency checker==


I wish I had a tool like that last year... Showing
I wish I had a tool like that last year... Showing
Line 94: Line 92:
would be a good addition to polisher  
would be a good addition to polisher  


===Special doc pages===
==Special doc pages==


A special page will show a list of the new rubygem review requests of bugzilla and in particular those marked as NEEDSPONSOR.
A special page will show a list of the new rubygem review requests of bugzilla and in particular those marked as NEEDSPONSOR.


===Show info of gems to be packaged===
==Show info of gems to be packaged==


Right now, the fedoraruby app shows information only about packaged gems.
Right now, the fedoraruby app shows information only about packaged gems.


==A rough timeline for your progress==
=A rough timeline for your progress=


21/03 - 18/08
21/03 - 18/08


==Any other details you feel we should consider==
=Any other details you feel we should consider=


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


Yes, [[User:vondruch]]
Yes, [[User:vondruch]]


[[category:Summer coding 2014]]
[[category:Summer coding 2014]]

Revision as of 19:29, 19 March 2014

isitfedoraruby.com is a web-application built with Ruby on Rails, that keeps track of the Fedora/Ruby integration, especially gem -> rpm conversion.

The project was started on 2012 as a Google Summer Of Code project by User:Zuhao and later were added some new features during the Google Code In program. This is my idea of enhancing it from a packager's point of view.

An overview of your proposal

isitfedoraduby is a nice project that never got the attention it deserved. I believe this is because it serves merely as a portal of the gems packaged for Fedora, showing their statuses and some nice statistics and graphs.

Being a packager myself for almost a year now, I am familiar with the difficulties one has to overcome in order to package a gem. This idea aims to facilitate the packaging process by providing some new tools and promote the site among Fedora ruby packagers.

In particular, I have in mind to:

  • refactor the base code where needed
  • write rspec tests
  • enhance the gemfile_tool
  • implement a feature of gem/app packaging progress bar
  • show better formatted dependency checker
  • create a page with stats preview of a gem not yet packaged
  • use polisher gem where needed
  • write documentation and how-to guides of rubygem packaging
  • UI - UX changes

I will try to expand below each item.

The need you believe it fulfills

These enhancements will hopefully promote the site usage among Fedora ruby packagers and attract new ones.

For new packagers

Based on my experience as a new rubygem packager a year ago, I have compiled some useful information for the packaging process that would help new users to engage in ruby packaging much quicker than I did. You can read a draft here. This will be accessed through a special docs page on isitfedoraruby.com and could be edited with pull requests in the github repo.

I also plan to document the workflow a packager follows to build/update a gem, the tools needed to achieve this and the ones that would make the process easier, e.g. using the polisher gem and its binaries.

Of course documentation is not the only important thing, new packagers could also use the advanced features I describe below.

For existing packagers

The new enhancement that I have in mind for the gemfile_tool will help packagers that want to package an application with many dependencies. For example, Gitorious and GitLab are two big rails projects with over 100 dependencies each. The way gemfile_tool is now implemented isn't of much use. Using the polisher gem we can enhance it to depict the dependencies in a nice format (table maybe), export to json, display only the runtime dependencies, etc.

Any relevant experience you have

How you intend to implement your proposal

Refactor basecode where needed

Write rspec tests

Currently we have almost none.

Enhance gemfile_tool

That would be really awesome as it would really facilitate the work done by someone who wants to package a gem with many deps or a rails app like GitLab or Gitorious that Ken is on. Now, with the work you have done in polisher that would be easier to implement. I was thinking that it could even speak to the API (supposedly there is one) and with the help of mediawiki-gateway [0] it would spit a table like the one I have for GitLab [1] (I use semi-automatic methods for now). It could also spit some json format like the one I create here [2]. And the list goes on

Packaging progress of a rails app or a gem

Separate page that describes the packaging progress of a gem with many dependencies or a rails app with tons of dependencies. My original thought is that if someone wants to watch the progress of a gem/rails app, they could do on such a page with a progress bar. The user that handles that packaging (here we need the User logic I described earlier), submits a Gemfile{,.lock} and he can choose which groups (production, development, test, etc) to submit (since polisher now has this function). Then for each gem that gets in rawhide, the progress bar gets a little further. That's a draft in my head...


Enhance dependency checker

I wish I had a tool like that last year... Showing the deps in a more elaborate way, that would make my packaging a lot easier. Now it presents gems' dependencies in a tree and that's cool, but I'd love to enhance it and show them in a table format like:

gem1

 |- gem2
 |- gem3
     |- gem4

Also, it currently depicts the tree of gems already packaged. What if I wanted to see a gem's dependencies not yet in the repos? Actually that would be a good addition to polisher

Special doc pages

A special page will show a list of the new rubygem review requests of bugzilla and in particular those marked as NEEDSPONSOR.

Show info of gems to be packaged

Right now, the fedoraruby app shows information only about packaged gems.

A rough timeline for your progress

21/03 - 18/08

Any other details you feel we should consider

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

Yes, User:vondruch