Summer of Code 2009

From openSUSE

(Difference between revisions)
Revision as of 18:29, 4 March 2009
Colyli (Talk | contribs)
Porting openSuSE to MIPS platform
� Previous diff
Revision as of 18:29, 4 March 2009
Colyli (Talk | contribs)
Porting openSuSE to MIPS platform
Next diff →
Line 179: Line 179:
'''Skill level:''' high '''Skill level:''' high
-'''Mentor:'''+'''Mentor:''' [mailto:coly.li@suse.de Coly Li]
== Integration of class based build system (e. g. BitBake) with openSUSE == == Integration of class based build system (e. g. BitBake) with openSUSE ==

Revision as of 18:29, 4 March 2009

(Back to the main Summer of Code page)

This is our page of ideas for the Google Summer of Code 2009. If you are a student, you can participate by developing one of the projects we describe here (or propose an idea of your own!), and get paid through a stipend by Google. You will be mentored by an experienced member of the openSUSE community. Read the Google Summer of Code 2009 FAQ for more details about the program.

Note that Google hasn't announced the list of accepted projects yet. So all this is under the assumption that openSUSE is accepted to participate in the Google Summer of Code 2009.

Are you a student? See information for students below.

Do you want to mentor a student? Start by reading the Summer of Code Mentoring HOWTO. Then add your ideas and your name to the ideas list.

Contents

Organization

The openSUSE projects needs a small team of people organizing the Google Summer of Code event. If you like to help with the organization, please add your name:

  • NN

Organizing includes:

  • fill the application form for the project. It's not really a long task, but well, it has to be done :-)
  • find potential mentors and have them all register on the GSoC website
  • push the community to propose project ideas, and triage them for the potential GSoC participants
  • review GSoC applications and help create consensus on which students get selected
  • during GSoC, be available to help mentors and/or students; make sure there's good communication going on, and also try to push the students to advertize their work.
  • make sure all mentors fill the review forms.
  • monitor the GSoC mailing list to generally do the right thing :-)

Important dates

  • March 9 to March 13 - Mentor organization application period
  • March 18 - Announcement of accepted mentor organizations.
  • March 23 to April 3 - Student application period
  • April 20 - Announcement of accepted students
  • May 23 to August 17 - Coding period

See the authorative timeline for more details.

Information for students

The Google Summer of Code is a program for students in most countries. You will participate by writing code for a free software project. Students who finish their work satisfactorily will get a stipend of 4500 US Dollars.

Do this if you want to participate:

  1. Start by reading the Google Summer of Code FAQ
  2. See which of the Ideas below you find interesting or come up with your own idea.
  3. Get in contact with the community
  4. If openSUSE is accepted as mentor organization, submit your proposal on the Google Summer of Code website

Your proposal should include this information:

  • Give a detailed idea of what you want to accomplish in your project. Don't just quote what the project's abstract says! Think of how you will actually implement it, and describe that.
  • Give a general idea of your skills. If you have participated in a free software project before, say so and if possible point to your contributions.
  • Give a rough timeline for your work, with milestones. For example: "week 1, get the code to build and start familiarizing myself with it. Week 2, implement the first refactoring patch. Week 3, try such and such thing."

Basically, let us know why you are the perfect person to implement the project you picked :)

Ideas

This is a list of ideas for projects which could be done for openSUSE as part of the Google Summer of Code program. If you have an idea and want to mentor it, please add it it to the list.

If you are a student and want to work on an idea, submit a proposal. You are not limited to the ideas listed here. If you have an own idea or want to approach an idea in a completely different way, feel free to submit this as proposal as well. Sometimes these are the best projects. Creativity and initiative are highly appreciated.

Two other great sources for openSUSE related ideas are openFATE and idea.opensuse.org.

openSUSE Build Service

OpenID support for the Build Service

OpenID is an open distributed authentication system, which allows users to use one account to login to many web sites, while giving them full control of how account data is used. If the openSUSE Build Service would allow OpenID logins, users wouldn't have to create extra accounts to be able to use the Build Service.

The task of this project is to add OpenID support to the Build Service, so that it's able to act as OpenID consumer, allowing users to login with their existing OpenID account. This involves refactoring the login infrastructure in the build service frontend, adding OpenID support to it, and implement an UI for logging in via OpenID and managing the user's OpenIDs.

Required knowledge: Ruby and Ruby on Rails would be an advantage, as the Build Service frontend and web interface are written in Rails. OpenID experience would be a plus as well. Both can be learned while going, though.

Skill level: medium

Mentor: Cornelius Schumacher

Automatic package approval and management system for a rolling release

The goal is to improve usage of new applications in openSUSE between the major distro releases. This will help the next complete openSUSE distro and also the open source community at large as not all testing and integration has to be done in one big project. To achive this a new openSUSE repository, RollingRelease is suggested.

The project has multiple sides.

First to add a voting system to the packages in the OBS service. The votes shall then be used to decide which packages can be added to the RollingRelease repository.

Secondly the system must make a check on the dependencies of the packages and see that it matches the dependencies in the RollingRelease repository and also match the dependencies from the base packages from the latest release openSUSE distro.

If the voted packages then match the selected criteria, then the package is copied in to the RollingRelease repository and should be available as an update to the users subscribing to the repository.


Required knowledge: Ruby and Ruby on Rails would be an advantage, as the Build Service frontend and web interface are written in Rails.

Idea: Birger Kollstrand , Idea discussed on the openSUSE Project mailing list

Skill level: medium ?

Mentor: [mailto:]

Multi-Package Submit Request

Modern version control systems use changesets. A changeset consist of different single changes that only make sense if they are applied together. A similar scenario exists when submitting packages: some changes depend on other changes in different packages. Therefore the Build Service should be able to handle such submission as one.

Required knowledge: Ruby and Ruby on Rails would be an advantage, as the Build Service frontend and web interface are written in Rails.

Skill level: n.n.

Mentor: n.n.

Education Project Ideas

openSIS-MySQL is a project started to move this very important education administration software to MySqL. With the completion of this project the software would be ready for integration with Moodle, international education database standards and languages.

Required Knowledge: PHP, Ajax, ADOdb, MySQL, PostgreSQL

Skill level: medium-high

Mentor: os4ed team

Software Portal

openSUSE Software portal offers to search for packages for several distributions (e.g., openSUSE, Fedora, Ubuntu, ...) and openSUSE Build Service offers to build packages for these distributions. However we would like to extend the package search with some in/out functionality.

  • Packages popularity (statistics based on search results, one click install functionality, etc.)
  • Category-based search (to identify preferred choice, stable/experimental, etc.)

Required Knowledge:

Skill level:

Mentor:

Upstream Bugzilla Enhancements

Upstream Bugzilla is an application widely used by several open source project, e.g., by Mozilla, RedHat, GNOME, KDE. It would be nice to have unified usability extensions for reporting bugs. We'd like to make bug reporting and searching easier and/or (partly) automated.

  • Crash Catcher - an automatic bug-reporting tool
  • Off-line reports

Required Knowledge:

Skill level:

Mentor:

Codecs and Drivers Installation

Not only desktop-based systems could profit from an integrated solution for identifying needed codecs and drivers, downloading and installing them (for instance based on PackageKit). This might be connected with the Software Portal.

Examples of usage:

  • Firefox plug-ins
  • MPlayer and Kaffeine audio and video codecs
  • WiFi and video cards drivers
  • ...

Required Knowledge:

Skill level:

Mentor:

AdminKit

AdminKit is a distribution-independent PolicyKit-based framework for allowing user applications to run administration tasks. We'd like to extend and implement this idea and integrate it into applications and windowmanagers.

See also Rodrigo Moya's blog

Required Knowledge:

Skill level:

Mentor:

Porting openSuSE to MIPS platform

MIPS processes are used in netbook solution more and more, e.g. YeeLoong or Gdium with loognson processes (mips64). Most of MIPS netbook users use debian and a few of them use Mandriva. This project will develop a USB bootable openSuSE distribution (prototype) running on MIPS netbook (here it is loongson processor). As a result, openSuSE is promoted to a new platform, and MIPS users have a more option to the excited experience of freedom.

Detailed information will come soon.

Required Knowledge: Cross compiling, Linux from scratch on MIPS, openSuSE system management and configuration, wide programming skill to resolve porting problems

Skill level: high

Mentor: Coly Li

Integration of class based build system (e. g. BitBake) with openSUSE

Using recipes and classes of a class based build systems make packaging work much easier than static build dexcriptions. Developers just have to create a simple recipe: include correct class and define its properties and exceptions. Changes to build of similar packages (e. g. GNOME packages, perl packages, python packages) or changes of generic rules could mean just one class change instead of changing of many packages at once.

To perform such integration, student should implement these steps:

  • research on available class based systems that support binary packages: BitBake, PiSi, Conary
  • implement advanced support for rpm output (dependencies, scripts, tags)
  • communicate with the tool upstream
  • provide initial set of classes and recipes for packages conforming to packaging conventions
  • prepare the tool for integration with openSUSE Build Service

Required Knowledge: General knowledge of packaging, language of class based system (most probably Python), knowledge of class based build systems is welcome

Skill level: packaging: medium, programming: medium

Mentor: Stanislav Brabec

Sync with Mobile Devices

The worldwide market is currently filled up with several smart phones. Almost all mobile devices contain some kind of organizer, camera, audio recorder, etc. Users would like to synchronize their mobile devices with applications but they often fail.

Google-related examples of usage:

  • Picasa Web Albums
  • Google Calendar

Required Knowledge: Basic orientation in used technologies (SyncML, OBEX, ...) is good starting point.

Skill level: medium-high

Mentor: Michal ÄŒihaÅ™

Configuration and Package Management Rollback

This is one of the most wanted features by broad group of users.

The solution doesn't have to be distribution-specific if we stick to using generic open-source tools. One idea is to use LVM snapshots for system partitions. Reverting to a snapshot would solve both, configuration and package management rollback.

Required Knowledge:

Skill level:

Mentor:

Key Management for Software Management Stack

As Internet is wider and wider every day, importance of security still raises. All software that users download from Internet, all repositories should be signed. It also means that users should be able to check these signatures easily.

For instance, we could use the same easy to use method as, e.g., Mozilla Thunderbird: public GPG key servers (downloading unknown keys, validation, reporting issues).

Required Knowledge:

Skill level:

Mentor:

Upstream version tracker as web service

We currently have no automatic way to make sure we have the latest versions of a package. Debian implemented an external health status website to help them know how they're doing. The openSUSE GNOME team implemented something similar to this as part of the infrastructure for the osc gnome plugin, but it has some limitations.

This tracker would be able to track the latest upstream version for all modules, but also to track the latest upstream version on a given branch. It should contain not just the version, but also an URL to the tarball and also possibly the md5sum/sha1sum and other useful metadata. This service could be made available in a distribution-agnostic way.

Required knowledge: good knowledge of some programming language can help. There's some preliminary code in python that could be reused.

Skill level: medium

Mentor: Vincent Untz

YaST ideas

See YaST Research Page.

Links