Student Deadline is over!

The student deadline is over, it's time to rate for the orgs. I have seen in my student dashboard a "dancing dates" in last modified field, this means rating or comment. GNU/Debian guys were the ones that comment my applications and are the ones too that are doing something "visible".
Waiting!!!

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.

GNU/DEBIAN and UBUNTU: Possibility to comment and rate packages in Synaptic

Abstract

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.
My idea is to give synaptic the infraestruture to make comments and rate the packages by the users.
To develop the idea, synaptic need an external centralized system to store the data.

Scenario

I'm a user, when I was installing some package did some postinstall configuration, I comment it in synaptic for the community.
The same user discover a free good game in the repository, he rate it.
Other user looking for a good video player, do a search and select the most rated one, reading the comments of other users.

Description

The project will improve the features of synaptic giving some community direct interaction with the package system. 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.

Domain

User looking for new software or feathures.
Packages and package system (apt).
User who like to share his experience.

Desing autodiscussion

We need some infraestructure to store online the comments and the ranking.

User control? I think no, only a username
And the trolls? a sysop, a moderator?
Bandwith problems? a mirror system. replicate and propagate the changes.
Get the comments on demand will be best option.
Get the ranking should be very fast (its only a number) to sort lot of packages by ranking.
The ranking system should be separately from the comments systems.
What kind of data for the comments, some rich text, quotes, bullets, links.
Possibiliti to deactivate de comments and the ranking system

Use Cases

1: right click in a package --->contextual menu with the usual options, "rate", "add comment", "read comments" .
2: select "rate"---> submenu with stars rate system
3:select number of stars ---> "rate successful" and store information.
4: select "add comment"--->display a window with a text field to add coments and a button "OK"
5: select ok --> store the comment.
6: select "read comments"-->download the comments about a package and show it pagining.
7: sort by ranking -->current packages view is sorted by rank

Roadmap

1. Modelize the store system, decide the best option.
   
2. Study the synaptic source, get some feedback from the project admins
3. UMLize the project.
4. Coding a prototype of the ranking system.
5. Test and retest, get some feedback.
6. De-bug the code. repeat 5,6 until I'm happy.
   
7. Codding a prototype of the comments system.
8. Test and retest, get some feedback, take care about load times.
9. De-bug the code. repeat 8,9 until I'm very happy.
10. Look for the propagate system, do some test with more users, diferent mirrors etc...
11. inprove and inprove.

Possible problems

Data incosistensy through mirrors
Server congestion.
Trolls, spam,

Possible security problems

Trust the data
Privacity for the users

DEBIAN: Apt Checkpoint

Abstract
Sometimes, a GNU/Debian user becomes crazy and install a lot of packages, sometimes with repeated features. Then the user tests the software and want to rollback to previous state.
In other hand, a developer find an issue in a package, then install the build dependencies, and fix the problems. When the problems are fixed the developer may want rollback to her old state, keeping the updates but removing or downgrading the packages installed to satisfy the build dependencies. In this cases, a rollback software will do the life easier.

There is an existing project "apt-checkpoint" on sourceforge which has last been worked on in 2004 (version 0.1), written in Python. Maybe it can serve as a basis.

Domain

A user set checkpoints on package system (apt), some packages without possibility to rollback.
A user want to rollback to old system.
A developper want to do a diferencial rollback when finish some project because in his work use a diferent version of gcc, or libraries... set a first differential checkpoint (or a rollback point, it's the same), install build dependencies for something, set a second differential checkpoint. The packages between the first and the second checkpoint will be the ones rollbacked.

Scenario

A system administrator would like to do a snapshot of his GNU/Debian system for some reasons:

• Check new versions with a go back step if something go wrong
• Save his "perfect configuration"
• Clean the system whenever.

Self desing discuss

First we need an exhaustive list of packages which could be problematic to rollback, then we need a system to detect new packages with the same problems.

The security it's no trivial here, we need trust the packages to goback to older versions.

The checkpoint should be like apt tools, and easy to use.

What if a version of a package is not in the repository: ignore, ask,lookfor, give the url? needle to study the best option.
apt-repack maybe a good option when a package version is not in the repository (if we select the option to cache the packages which arent in the repositories)


Use cases

0: Admin--->"apt-checkpoint set": mesagge, "you are going to set a checkpoint in ($now), the follow packages and her dependecies can not be rolledback, are you sure (Y/n)"
1:Admin---> Select yes: save the state of the package system, encript and set date time and ID
2: Admin --->"apt-checkpoint rollback": show a list of posible checkpoints numbered to select one of them.
3:Admin ---> select one checkpoint: show the list of changes and "continue Y/n"
4: Admin --->select Y and enter: the packages rollback to the old state.
5:Admin ---> select no: exit.
6: Developer -->"apt-checkpoint set-differential first": mesagge, "you are going to set a first diferential checkpoint in ($now), are you sure (Y/n)"
7: Developer -->"apt-checkpoint set-differential second": mesagge, "you are going to set a second diferential checkpoint in ($now), the follow packages may be rollback.($list of packages) are you sure (Y/n)"
8: Developer -->"apt-checkpoint diffrollback": Select what differential checkpoint you want ($List of diferential checkpoints, ordered by date)
9: Developer ---> select one checkpoint: show the list of changes and "continue Y/n"
10: Developer --->select Y and enter: the packages rollback to the old state.
11:Developer ---> select no: exit.

Roadmap

1. Study the possible rollback problems, decide what to do with configuration files (save the checkpointed, ask, nothing...) light task back not trivial
   
2. Study the existing apt-get checkpoint project, contact with the developer if is possible. Study code form others usually is complex.
   
3. Decide a new name for the project. (semitrivial task :))
   
4. Modelize the checkpoint store system, what need to save to rollback, how store (XML gziped..., plain text files, a mix, databased, packages cache...). A hard task, and very important
   
5. UML modeling.
   
6. Coding to prototype.
7. Test get some feedback
   
8. GOTO 6.
   

Security problems

the packages and the information checkpoints must be trusted.

Possible problems

For some packages, diferent versions of configuration files has not backward compatibility.

Contributors
Erich Schubert send me two comments, one about apt-repack and other requesting the differrential feature.