The Linux Foundation

 
Google Summer of Code 2009

From The Linux Foundation

Revision as of 20:50, 10 February 2010 by Khoroshilov (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

This is our list of project ideas for the Google Summer of Code program in 2009. We got 25 student applications in the two business weeks of application period and they are covering most of our suggested project ideas. We got 11 student slots from Google and 6 students are currently working on OpenPrinting projects, 1 on an LSB project, 3 on WLAN projects, and 1 on a kernel project.

On all projects where students will work on this summer we have listed the names of the students. All other projects are not currently worked on (any volunteers?). Congratulations to all the students whose proposals got accepted into this Google Summer of Code!


Here is the list of project ideas:

Contents

Driver Backports

Mailing list: lf_driver_backport at lists dot linux-foundation dot org

Code License: GPL

Kernel

Mailing list: http://kernelnewbies.org/MailingList

IRC: http://kernelnewbies.org/IRC

Code License: GPL

IEC 68831-6 support for the new FireWire stack

IEC 68831-6 (AMDTP) is the standard for most (semi-) professional FireWire audio interfaces. Currently, support in Linux for such devices is provided by the FFADO daemon, which relies on libraw1394 library.

This project sets the goal of partly moving into the kernel (as a FireWire driver with an ALSA interface) what FFADO currently implements in userspace.

THe impact: huge! It will push Linux even further in becoming a top choice as a music recording and production platform!

Student: Mircea Gherzan

Mentor: Pieter Palmers

Optimized netfilter implementation

Currently netfilter packet classification is an interpreter that applies chains of rules to every packet in the system. This can add thousands of cpu cycles of per packet overhead for a reasonably simple set of iptables rules.

Dynamic code generation could be used to significantly reduce this overhead.

See netfilter.org and the netfilter-devel mailing list.

LSB

Mailing list: lsb-discuss at lists dot linux-foundation dot org

IRC: #lsb on irc.linux-foundation.org

Workgroup Resources

Code License: GPL/BSD, specs: GNU FDL

Make OpenJDK LSB Compliant

Including Java as a mandatory component in the LSB (similar to the support of Perl and Python) has been difficult due to some non-technical issues. As a community we recognize the importance of Java and would like to provide a pathway for Java application to become LSB certified. Therefore, the creation of an LSB certifiable JRE is very important to community and a number of Java application providers.

The Sun Java runtime environment uses a number of interfaces which are not yet in the LSB 4.0. A list of those interfaces can be found in the LSB Database Navigator. In some cases, LSB compliance issues can be easily fixed by simply compiling Java Runtime using different compiler options, or by using the lsbcc wrapper to gcc. In other cases, simple substitutions (using posix_memalign instead of memalign) is all that is required. However, not all non-LSB libraries and interfaces used by OpenJDK will be as easy to solve.

The goal of this project is to analyze the open source OpenJDK Java Run-Time Environment and create patches (hopefully acceptable to the OpenJDK upstream) so that it can be built as an LSB-complaint application. The patches should not break Java compliance (although formal testing against the TCK will likely be beyond the scope of this project) and should not impact performance (as measured by Specjvm2008) unduly. The student who applies for this project should be familiar with C and C++ programming, and enough Java experience to be able to run Java test programs. Familiarity with the LSB project and with the OpenJDK projects is highly desirable.

Student: Pavel Shved

Mentor: Jeff Licquia(?), the LSB workgroup

Desired Knowledge: C and C++, Java, experience with LSB and/or OpenJDK

Code license: GPL V2 with Classpath exception

OpenPrinting

Mailing list: printing-architecture at lists dot linux-foundation dot org

IRC: #openprinting on irc.linux-foundation.org

OpenPrinting developer resources

Code License: See project descriptions

Common Printing Dialog: Coding on the dialog designed by OpenUsability, for KDE and/or GNOME

At the OSDL Printing Summit in Atlanta in April 2006 usability experts from OpenUsability were present and kicked off the design of a common printing dialog for all desktops and applications under Linux. This dialog is once designed with usability in mind, studies about potential user groups and printer types were performed, paper prototyping and interaction design done, ... and second, the overall usabilty of Linux will be improved by having the same printing dialog everywhere.

Now, near three years later, the design is completed and specifications for the dialog and its integration are available. Based on these specifications driver developers/printer manufacturers will be able to fit their drivers to the dialog and application and desktop programmers will be able to implement the common dialog. Implementation of a Qt-based and a GTK-based dialog has been started in the Google Summer of Code 2008. See the project page of the Common Printing Dialog.

The current roadmap is the following: As a first stage Lars Uebernickel, former GSoC student who implemented the D-Bus interface to couple the dialog with the applications (CPDAPI) and who also implemented the GTK GUI of the dialog, works on patching the GTK and Qt libraries so that applications call the printing dialog via CPDAPI leading to the case that the printing dialog comes from the desktop: If you run GNOME you see the GNOME dialog, also if you print from non-GNOME applications, same for KDE. In this stage we stay with the standard printing dialogs from GNOME and KDE.

The second stage will be the introduction of the dialog designed by OpenUsability. This requires two important coding tasks: First, the dialogs have to be finished, second, common desktop applications, like OpenOffice.org, Firefox, Thunderbird, the GIMP, digikam, ... have to be modified to directly use the CPDAPI (and not using the standard functions of the toolkits). This is needed, as the toolkit APIs do not support a printing dialog with integrated live preview.

For these coding tasks we like to have two students doing them as a Google Summer of Code project. The students should be familiar with GUI programming, preferably with Qt and/or GTK. They also need the ability to dive into existing code and to modify and continue working on it, as here ther is nothing new done from scratch. There is already code available. The dialogs are far from ready. A live preview needs to be implemented which changes on a simple change of an option. The dialog also needs to lay out option widgets dynamically and should put them into the dialog in an attractive and easy to overview way. And it needs to be tested with appropriately extended but also with legacy PPD files. The second student has to analyse the code of applications and to see how they generate print jobs and open a printing dialog. He has to do the modifications so that the application talks bi-directionally with the dialog via D-Bus, being able to generate the live preview.

And the most important: The two students have to work in a team, as the second student's modified applications have to communicate with the first student's dialogs.

Students: Per Hermansson (GTK dialog), Alexander Wauck (Qt dialog), Svilen Kanev (application patching)

Mentors: Lars Uebernickel, developer of Foomatic 4.0, CDPAPI, implementations of the OpenUsability printing dialog (larsuebernickel at gmx dot de), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till dot kamppeter at gmail dot com).

Desired knowledge: C/C++, GUI programming with Qt and/or GTK, modifying existing code

Code License: GPL/LGPL/Licenses of common desktop applications

Code Repositories: Common Printing Dialog D-Bus API (CPDAPI), Common Printing Dialog from OpenUsability

OpenPrinting database: Web-based (CGI) software for reviewing and uploading manufacturer/driver-developer-contributed printer drivers and PPD files

The OpenPrinting database is the principal source of information about which printers work how well with Linux and how one gets them actually to work. The database is not only available on the OpenPrinting web site but also locally installable and most Linux distributions have it locally installed to provide the printer model and driver information to their printer setup tools and to integrate the printer drivers with the printing system (usually CUPS).

We have the OpenPrinting web site which lists printers and drivers which make them work under Linux and in addition, we want to provide drivers for download in the form of LSB-based distribution-independent binary packages. As distributions are supposed to download them automatically the packages and the associated database entries need to fulfill certain requirements.

The driver management web application should deal with package uploads, automatic checks of signatures/uploader authentication, automatic checks for whether the package fulfills certain requirements, automatic extraction of contained PPD files and/or XML files and creation of appropriate printer entries, ..., automatic upload into the archives and update of the indices for the distribution's package managers, and in the end an automatic posting of an announcement for the availability of a new driver. The app should also notify the uploader and the server's administrator about the status of the process and in the case if human corrections are needed.

The printer/driver database is XML (the Foomatic database which is also locally installed on current Linux distributions) and the web app for browsing the database and the web query API are written in Perl, like the core engine of the database (the PPD generator which is the foomatic-db-engine package in the distros). This concept was chosen so that the database can also be used in local installations without needing an extra daemon, like it is usually used for SQL databases.

There is also a web app (made in the GSoC 2008) to manage user-contributed printer entries and comments, to easily remove spam and otherwise not useful contributions, to merge duplicates and to finally transfer good contributions into the Foomatic database, so that they provide PPD files and get used by locally installed printer setup tools.

One goal of the project is to have one consistent administration web app for the OpenPrinting web site. So your driver/PPD management part should integrate with this user contribution management part.

To get started, and find out what this all is about, you should once download the BZR repository of the current web apps: The first is the current state of the browsing web app, the second is the current state of the user contribution management web app plus an older version of the browsing web app. See the instructions on using our BZR repositories. They are also valid for the web apps.

You should also contact the developer of the user contributions management web app, Subhankar Sett (subhankar dot sett at gmail dotcom) to get familiar with his work.

It would be great if you try it out locally and do some improvements on it, as it is not yet 100% ready, for example to make merging of two entries work, where the two entries can be both user contributions, or one a Foomatic entry and the other a user contribution or both Foomatic entries. Or getting entries queued up to be committed into the Foomatic BZR actually committed.

What is yet missing to have it on our site is also to create a contributor/uploader/admin authentication based on the Linux Foundation user name and password (the ones you use also for the Wiki). Due to the high amount of spam also the simple contribution of a comment or a printer is planned to require to be logged in.

This would be preferably done as a PHP5 web application running on the server on which the OpenPrinting database is running, or on a server where the backend can connect to Linux Foundation resources. This way a moderator (who logs in with his Linux Foundation credentials via LDAP) could quickly triage new entries to get the good ones quickly into Foomatic and the bad ones quickly deleted to finally get the valuable user contributions into the Linux distributions.

Student: Kevin Seitz

Mentor: Dan Lopez, Web Development Manager, Linux Foundation (dlopez at linuxfoundation dot org)

Co-Mentor: Till Kamppeter, OpenPrinting manager and maintainer of the OpenPrinting database and Foomatic software (till dot kamppeter at gmail dot com)

Desired knowledge: PHP5, Smarty, Memcache, MySQL, XML, HTML, CGI programming, Perl, LDAP, Javascript, printing under Linux

Code License: GPL

Code Repository: OpenPrinting database web app

OpenPrinting database: Make the web-based application for browsing the database less resource-consuming using MySQL

The current OpenPrinting database consists of XML files for each printer, each driver, and each option (see the foomatic-db package on any Linux distribution, or /usr/share/foomatic/). This allows the user to have it locally installed and used by CUPS or by the printer setup tools without need of a database daemon. This works well on a typical system where finding a driver for a given printer is a task which perhaps happens once in a year.

The same XML database is also used by the OpenPrinting web site, where thousands of users are looking for a suitable printer driver every day. Even after several performance improvements of the existing Perl CGI scripts it often has major load peaks and long answering times, or even failures on user requests. It also takes hours to rebuild the web page html file cache if changes are done in the XML database.

The proposed improvement is now to create a PHP5 MySQL database driven web application to browse the OpenPrinting database. Using MySQL as a backend for web sites is very common and should give a much higher performance. The web front end should use PHP5, Smarty Templates, and memcache for performance and scalability. The web application should adhere to Object Oriented code design patterns. The application should use the following technologies PHP5, Smarty, Memcache, XML, HTML, Perl, MySQL, LDAP (to authenticate users). The system should also have access control lists (ACL) to have administrators, maintainers/managers, users, and anonymous users access different parts of the system.

The new web application will have Perl or PHP CLI scripts to automate the build of the printer XML database on a routine basis. The "original" Foomatic printer database should remain XML, managed in the BZR repository, but driver uploads to the new PHP5 MySQL web application will have a scheduled cron to rebuild the printer XML database into the BZR repository and for download. The Foomatic XML schema should be migrated and normalized into MySQL so that the database is searchable for all Foomatic metadata. User-contributed printers and user comments get updated in the MySQL database as soon as they are done. This way everything stays the same for local installations of Foomatic, but the site performance should improve a lot.

Student: Subhankar Sett

Mentors: Dan Lopez, Web Development Manager, Linux Foundation (dlopez at linuxfoundation dot org), Till Kamppeter, OpenPrinting manager and maintainer of the OpenPrinting database and Foomatic software (till dot kamppeter at gmail dot com)

Desired knowledge: PHP5, Smarty, Memcache, XML, HTML, CGI programming, Perl, MySQL, LDAP, Javascript

Code License: GPL

Code Repository: OpenPrinting database web app

Vendor WIN32 driver made available to Linux applications

There was a Google Summer of Code 2007 project under wine [1] to use WIN32 drivers to print from wine, and some adaption of that idea in some limited fashion in ddiwrapper [2]. It would be quite interesting and useful to properly integrate this into the more general printing workflow:

  • make it possible to print from linux applications through cups or other spoolers with more(all?) WIN32 drivers

Currently there are two(?) frameworks which are usable for loading binary-only closed-source vendor driver modules, OPVP and IJS. There are a few other FOSS projects which uses some part of wine to load binary-only WIN32 modules for accessing data in proprietary format quite successfully - e.g. ndiswrapper (for wireless network hardware), mplayer (for multimedia playback).

Some background information is in [3]

Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols; Detlef Riekenberg from the Wine Project, who was the mentor for the Gsoc 2007 wine project for print proxy, has agreed to be involved.

Desired knowledge: C programming

Code License: GPL/LGPL/Public Domain

JTAPI implementation

Job tickets are extended descriptions for print jobs. They tell which documents should be printed, on which type of paper, which resolution and quality, whether there should be sheets inserted between the documents, ..., and even information like delivery address, payment, ... A job ticket accompanies a print job from its submission to its delivery. Job tickets come from the professional printing world. In former times they were a paper form with instructions what everyone involved in the printing process has to do. Nowadays they are standardized files which are used by print servers, printers, and production printing machines. These job tickets do not only make sense for large-scale production printing, they are also useful for mobile devices, home desktops, workgroup printers, ... Also access to print services on the internet directly from the desktop applications simply via a print queue would be possible.

To allow desktop applications, printing systems, and printer drivers to easily create, edit, and read job tickets without needing to deal with the actual job ticket format, the job ticket application programming interface (JTAPI) was developed by OpenPrinting. A complete specification is published.

The next step to do is the actual implementation of the JTAPI library and its integration in applications, the CUPS printing system, drivers, filters, ... This will be the task of the student in this Google Summer of Code project.


Proposed Tasking:

Objective: Using the header files created by the Open-Printing Job-Ticket Working Group develop a platform independent C library for the reading-of, modification-of and storage-of a print job ticket for the Printer Working Group’s (PWG’s) Micro-Job-Ticket (MJT).

Approach:

  1. Review OP/JTWG Job-Ticket Application Programming Interface (JTAPI)header documents
  2. Review PWG/MJT specification.
  3. Create Test MJT’s
    1. Manually create a minimum of 3 representative MJTs (text files) to be used for testing and evaluation
  4. Define the command-line Test Application to exercise the JTAPIs; include an initial set of commands
  5. Create Thin-Thread implementation of the individual JTAPIs and the Test Application.
    1. This will be the first demonstrational implementation and the start code for detailed development.
    2. This will include minimum documentation on how to use the Test Application
  6. Enhance individual JTAPIs and the Test Application to provide full functionality.
    1. Provided update documentation as required.
  7. Project Demonstration.


Code License: CPL

Coding Language: Platform Independent C (No platform or vendor-specific extensions)

Coding Document: In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.

Operating System: Student’s choice – Linux or Windows (non-gui for either)

Interface: Command Line – GUI not required unless very simple (due to project time constraint)

Document: Minimum:

  1. How to build the JTAPI library.
  2. How to build the Test Application
  3. The Test Application command-line instructions
  4. Three examples of using the Test Application and exercising the JTAPIs

Student: Paul Victor

Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)

Desired knowledge: C Programming

JTAPI JDF Job-Ticket Implementation

Job tickets are extended descriptions for print jobs. They tell which documents should be printed, on which type of paper, which resolution and quality, whether there should be sheets inserted between the documents, ..., and even information like delivery address, payment, ... A job ticket accompanies a print job from its submission to its delivery. Job tickets come from the professional printing world. In former times they were a paper form with instructions what everyone involved in the printing process has to do. Nowadays they are standardized files which are used by print servers, printers, and production printing machines. These job tickets do not only make sense for large-scale production printing, they are also useful for mobile devices, home desktops, workgroup printers, ... Also access to print services on the internet directly from the desktop applications simply via a print queue would be possible.

To allow desktop applications, printing systems, and printer drivers to easily create, edit, and read job tickets without needing to deal with the actual job ticket format, the job ticket application programming interface (JTAPI) was developed by OpenPrinting. A complete specification is published.

This is a parallel project to actual implementation of the JTAPI library by providing a JDF Job-Ticket Front-End. This will be the task of the student in this Google Summer of Code project.


Proposed Tasking:

Objective: Using the header files created by the Open-Printing Job-Ticket Working Group develop a platform independent C module for accepting, parsing, interpreting and translating JDF Job-Tickets to JTAPI objects/attributes using the JTAPI's.

Approach:

  1. To Be Determined


Code License: CPL

Coding Language: Platform Independent C (No platform or vendor-specific extensions)

Coding Document: In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.

Operating System: Student’s choice – Linux or Windows (non-gui for either)

Interface: Command Line – GUI not required unless very simple (due to project time constraint)

Document: Minimum:

  1. How to build the JDF Job-Ticket Module.
  2. How to build the Test Application
  3. The Test Application command-line instructions
  4. Three examples of using the Test Application and exercising the JTAPIs


Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)

Desired knowledge: C Programming

Printer configuration backend for Oyranos

Print devices can be described by ICC profiles. These profiles should be communicated alongside the normal print pipeline. A module abstracting CUPS and other print spooler details for ICC profile communication would open the door of print previews for applications and configuration tools.

This project is in cooperation with the OpenICC organization which was also accepted for this years GSoC. So students interested in working on this and other color management related projects should also submit color management related proposals to the OpenICC organization as this will help OpenICC and the Linux Foundation to allocate the projects in an optimal way.

Student: Joe Simon (Mentored via the OpenICC organization)

Mentor:

  1. Hal V. Engel (hvengel at astound dot net) Students are encouraged to contact the mentor during the application process.

Expectations:

  1. Work with CUPS API's
  2. Extend CUPS to transport remote printer informations to the the Oyranos module
  3. Extend the KDE Kolor Manager module to support the new printing functionality

Oyranos module

  1. Inline documentation

Skills

  1. Good communication skills (work with different parties)
  2. Portable C

Oyranos Device Settings to ICC profile layer

Devices need to be introduced to a color management system, in order to control the color behavior of a device. For instance different drivers may produce different color on a otherwise identical device. A Color Management System (CMS) needs some mechanism to connect color influential device settings and driver informations and a particular color profile reflecting these settings. ICC profiles containing such information would allow for automating many user decisions.

This project is in cooperation with the OpenICC orginization which was also accepted for this years GSoC. So students interested in working on this and other color management related projects should also submit color management related proposals to the OpenICC organization as this will help OpenICC and the Linux Foundation to allocate the projects in an optimal way.

Overview and informations:

  1. http://www.oyranos.org/wiki/index.php?title=Device_Settings

Draft for new ICC color profile tag:

  1. http://www.oyranos.org/wiki/index.php?title=Device_Settings_in_ICC_0.2 (reading is implemented in Oyranos)

Mentor:

  1. Kai-Uwe Behrmann < ku dot b at gmx dot de >
  2. Robert Krawitz, ...
  3. Students are encouraged to contact the mentor during the application process.

Expectations

  1. Create and implement a API for inclusion of driver specific data into ICC profiles in a generic way
  2. Filter profiles according to their included generic driver informations
  3. Apply your API's to one device driver API, for instance Gutenprint, libopenraw or Sane to study their effects
  4. Document the API usage

Skills

  1. Portable C
  2. Have a working build environment before the project starts


Accessibility

Mailing list: accessibility at a11y dot org

IRC: #a11y on irc.linux-foundation.org

Accessibility developer resources

Code License: See project descriptions

Accessibility for Motif

There are many legacy Motif applications which are not accessible. It would be nice if there was a Motif to GAIL mapping library (libxm2gail) to enable accessibility in the Gnome desktop.

The way this would work is GAIL (the GNOME Accessibility Implementation Library) is itself a mapping library which maps the GtK+ widgets to ATK, the toolkit which GNOME uses to enable accessibility for users needing extra support to make the most of their computers. ATK is used by tools such as screen readers, magnifiers, and input devices to permit a rich interaction with the desktop through alternative means. See the ATK SourceForge Project and the ATK Library for more information.

Since the GtK+ widget set and the Motif widget sets are roughly at the same level of complexity, it is faster and easier to reuse the existing GAIL library to create a method of enabling Motif accessibility via the ATK library.

Mentors: TBD

Code License: LGPL (for GNOME); Open Motif License for any code that modifies OpenMotif.

802.11 Wireless

These are suggested projects to help enhance Linux wireless.

Mentors:

 * John Linville (Red Hat) linville at tuxdriver dot com
 * Dan Williams (Red Hat) dcbw at redhat dot com
 * Luis Rodriguez (Atheros Communications) lrodriguez at atheros dot com
 * Jouni Malinen (Atheros Communications) jmalinen at atheros dot com

Mentorship is also available using the public Linux wireless mailing listand the Linux wireless IRC channel.

Desired knowledge: C, knowledge of 802.11, Linux kernel development (not a complete requirement as some are completely in userspace), a choice of scripting language (python maybe?)

Further details can be found at the Linux wireless 2009 GSoC page

Add AP support to Network Manager

As of 2.6.29 the Linux kernel gets AP support for mac80211 drivers. We don't yet have any GUI based configuration utilities for AP support. Currently Network Manager uses wpa_supplicant for station configuration, a possible approach here is to use hostapd for AP configuration and usage.

License: GPL license for Network Manager extensions or kernel changes, BSD license for hostapd changes

Student: Witold Sowa

Mentor: Daniel Williams

Improve wireless roaming

Roaming support currently exists within wpa_supplicant, but there are no triggers to assist roaming within mac80211. This can be improved by providing triggers for scanning and sending the results to userspace. The triggers can be based on signal level but also can be based on location change and knowledge of previous AP locations based on historical seeds through the usage of GeoClue. We will ideally always want to roam to the closets and strongest AP seamlessly.

License: GPL license for Network Manager extensions or kernel changes, BSD license for wpa_supplicant changes, GNU LGPL license for any GeoClue changes

Integrate GeoClue to help with regulatory compliance

As part of our Linux wireless vendor support strategy we have added a new regulatory infrastructure as of the 2.6.28 kernel. Devices can specify their regulatory domain through different interfaces. Users can further help compliance by specifying their country. We can take advantage of applications such GeoClue to help compliance by making use of the different possible seeds of location we can get on a Linux system. One initial step here is to extend Network Manager to make use of the information supplied by GeoClue to be able to seed to wpa_supplicant the country which should be set for the current regulatory domain.

License: GPL license for Network Manager extensions, BSD license for wpa_supplicant changes, GNU LGPL license for any GeoClue changes

Student: Kalpana Roy

Mentor: Luis Rodriguez

Automation of testing using mac80211_hwsim and Orbit

We can use testing the robustness and functionality of the Linux wireless stack. Ideally we'd like to see automated tests run weekly to ensure there are no regressions for basic functionality. To test mac80211 and cfg80211 we can use and advance mac80211_hwsim as required without the need to actually use hardware. To test actual device drivers we can work with Orbit to use their existing hardware (or purchase new hardware) and infrastructure to automate routine tests. The idea is we'll have a set of standard tests the project developer will write in coordination with the Linux wireless development community. Each driver will run through the set of tests and we'll be able to determine whether or not each driver passes each individual test. We'll mark in green each passed test and with red each failed test. Ultimately it would be great to merge these efforts as part of the Linux Testing Project.

To get started start testing build the wireless-testing git tree and load the mac80211_hwsim driver. Then read the mac80211_hwsim documentation. Then start doing basic AP, STA testing as you would with two devices present on one system, one acting as an AP and another as a STA.

To start testing at Orbit read their documentation for developers and register for an account.

This work would involve becoming very familiar with 802.11 wireless technology in general, Linux wireless from a user perspective, and kernel side when enhancements are required. Recommended readings are the Oreilly book on 802.11 Networks.

Student: Georgy Berdyshev

Mentor: Luis Rodriguez


[Article] [Discussion] [View source] [History]