GNU/DEBIAN AND UBUNTU: Per Package Wiki and API

Abstract

This application is based on another application named "Possibility
to comment and rate packages in Synaptic" which was also written by
me. It was published on my blog and submitted to GSoC for the GNU/
Debian and Ubuntu organisations. I got a lot of feedback from the
mentor (Erich Schubert), from synaptic developers (Sebastian Heinlein)
and the Ubuntu and Debian community (ubuntuforums.com, #ubuntu-devel
in freenode, debian in freenode, the ULPGC software libre mailing
list, and everybody who send comments and critics).
Sometimes a new package makes your life easier, a music player, an editor, a new library... this don't come in the standard GNUDebian/(X|K|EDU)Ubuntu/Debian based distribution and it isn't too common to apperar in a guide. You discover the package thanks to a friend, a blog, a tutorial.
Every package has a "metaconscience" in the user comunity: screenshot, opinions, comments, Howtos, bugs, issues. That is named as user metainformation.

The idea is a community maintained metainformation system with an Api. The main frontend will be a like-wiki web application, crossing information from users and other sources like package repositories, popcon, debtags, debram, user tags...

http://wiki.debian.org/CRMI maybe a good starting point.

Some Use Cases

I'm a user, when I was installing some package did some postinstall configuration, I sing-in and add some comments to the package wiki and a howto link.

The same user discover a free good game in the repository, he rate it in the wiki and upload some screenshots.

Other user looking for a good video player, do a search and select the most rated one, reading the comments of other users in the web application.

A developer upload some screenshots about new features in his software.

Description

I'm the kind of guy that read and reread the "new packages" section, looking for good software, I think the feedback given by popularity contest is incomplete because the use of a package does not means that it is popular, only that a lot of people had installed. That people do not know if there is a better package for his necessities.

I apply for a way to know new and good software, to now bugs, to see screenshot, to talk about with users and developers and contributte with de project.

Desing autodiscussion

History and changelog from packages, some kind of package tracking.
User control.
And the trolls? a sysop, a moderator, a moderator team?
Bandwith problems? a mirror system. replicate and propagate the changes.
sort by package class/debtags/usertag/popcon...
Rate packages, user ranking? some kind of karma?
Some ajax will help, mind the step with this (requestrequet)

Details

I think this is a instance of Model-controller-View pattern. For the model I think in a relational database, postgresql or mysql.
I've have experience in Ruby on Rails and Perl Catalyst, I've preffer Ruby. Using REST (http://rest.blueoxen.net/cgi-bin/wiki.pl?RestInPlainEnglish) interfaces will help, added in 1.2 Ruby on Rails. Here http://weblog.infoworld.com/stratdev/archives/2007/01/rest_and_ruby_o.html
and here http://devnull.blogs.banot.net/articles/category/ruby Spanish (Richard Dale,rubyqt developer success history)
For some ajax (only where be necesary), the prototype rails pluging

Packages side

Package Info Tracker: in orther to retrieve new packages.gz and diff files from the repositories, calling the method which do the task to update.

Package Info Updater: Update the database, creating the wikipage, setting a directory (for screenshots). some lexical analisis for the packages.gz and de diff/* files

Package Info Model: Stored in relational database,

A package table with id(key) field, md5sum, name, section, mantainer, versions (with changelog), size, Arch.

A dependecies table with id, idpackage, idpackage, relation 1-*.

A suggested table, identica al anterior

Metainformation

Debtags, I dont know exacty how retrieve debtags, but in http://debtags.alioth.debian.org/cloud/, is a good example, I'm sure that it's possible and not too difficult.

Description Wiki alike, first filled which package description, next edited by the users, moderated by someway (maintainer, developet, wiki maintainer?). Some kind of text render like Textile http://whytheluckystiff.net/ruby/redcloth/
The model data is a table which Id, PackageId, UserId, Date, Description, last (boolean), keeping the history of changes.

The wiki controller, manage the modifications, log de changes, send to admin controller the changes to be approbed, recieve the approbation and make the changes in database.

Rating information

The model will be a table Id, PackageId, rate (float) 1-10. No history rates.

The rate controller, calc and set new the rate with (previousrate+newrate*Someuserkarma)/2, get rate from a package.

Usertags

I will use http://wiki.rubyonrails.org/rails/pages/ActsAsTaggablePluginHowto, for the model two tables, tags for tag info and taggings for relations

Comments

Database model, a table with commentid, comment, userid and another table id with id, packageid and commentid.

Users
Common user system with categories. The model are tables in the same database. The user controller will calc the user karma, I dont know the ways, investigate ¿Digg?.

Roadmap

1. Study the CRMI project, complete and decide.
   
2. Modelize the store system, decide the best option
   
1. Decide what metainformation we want to handle.
2. how store it? structure of files or/and databases
   
3. UMLize the project.
4. write some examples of metainfo
5. Package tracking
1. A bot generate the static information from the package system
   
6. Metainfo reader/writer class (some kind of adapter or control, look for paterns).
1. Possibility to set and get metainfo from the net.
7. A simply web frontend (to incremental approach)
   
8. The user control
1. some kind of user ranking or karma (need to discuss)
2. history of contributtions
   
9. Web frontend with user control
   
10. Test and retest, get some feedback.
11. De-bug the code. repeat 10,11 until I'm happy.
    
12. Look for the propagate system, do some test with more users, diferent mirrors etc...
13. inprove and inprove.

Possible problems

Data incosistensy through mirrors
Server congestion.
Trolls, spam.

Possible security problems

Trust the data
Privacity for the users

Application under Creative Commons Attribution License.