Archive:GSOC ideas 2011

(Redirected from openSUSE:GSOC 2011 Ideas)
Jump to: navigation, search

GSOC 2011 Idea list

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. The openSUSE GSOC 2011 page is here

If you are a student and want to work on an idea, please 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.

A great source for openSUSE related ideas is openFATE.

There have been a couple of ideas about more openSUSE derivates but it was decided that they are not good GSOC ideas as the coding part is not primal.

{TOPIC TO_BE_REPLACED}

{SUBTOPIC TO_BE_REPLACED}

Description of idea goes here, try and be as detailed as possible.

Required knowledge: What does the prospective student need to know before attempting this idea?.

Skill level: How difficult would this idea be to implement if the student has the required knowledge

Mentor: Name and contact will go here or MENTOR NEEDED.

Student: Name and contact will go here or STUDENT NEEDED.

A link to your implementation proposal will go here. This is not mandatory, but would be beneficial.

General ideas

  • Limited GUI support in text mode for multimedia & browsers.
  • develop a way for GTK apps to use a KDE file dialog in a Plasma Desktop
  • develop a way for KDE apps to use a GTK filedialog in a GTK desktop (GNOME, XFCE, LXDE)
  • Zypper to be able to talk to the 'osc' world so we can do zypper se on osc packages and trivially add repos, and install packages.
  • LTSP-GSOC Ideas
  • GRUB2 yast module
  • Remastersys for openSUSE
  • WebPin
  • Integration of owncloud
  • Improvements to KNetworkManager
  • Integrate Ksplice for reboot less kernel upgrades
  • FATE: Work on the KDE 4 client

FATE is the feature tracking framework of Novell/openSUSE. The user visible part of this is openFATE, the place where different projects of openSUSE track their feature requests. There also exists a KDE3 client, which should get ported to QT4.

ICC Device Profile Repository

Colour devices like printers, cameras, scanners and monitors should have a ICC profile to work flawless with colour managed applications. But where to find those? In the internet in a new to create data base. People can upload ICC profiles, measurement targets and more meta data. A rank or voting system should allow for easy search of the most popular profiles.

The site shall allow clients to send a request to obtain the ICC profile. Selecting a device inside a local client and pressing the get profile button should show up a simple selection dialog of available profiles and download the chosen one and install that.

Standard components would be great to use. One approach could be the combination of a public write only email list for sending in new data sets, a email list to commit data, a wiki to publish data and a daemon to answer search requests of clients.

Required knowledge:

Skill level:

  • good knowledge around data presentation
  • good communication

Mentor: Kai-Uwe Behrmann <ku.b@gmx.de>

Student: STUDENT NEEDED.


Ideas coming from openFATE

Overview: Features on openFATE tagged with 'gsoc_2011'

openSUSE Connect

openSUSE Karma plugin for openSUSE Connect

Implement Karma concept in openSUSE Connect that will collect points from wiki edits, bugzilla entries, planet.opensuse.org posts, distribution changelogs and possibly other sources and store them in the Connect. Also implement some UI to make it possible to send points. Create per group badget that will grow according of the number of skilled members automatically. Karma points should have some categorie - developer karma/marketing karma/... And it it would be also great to make it accessible though connect API (to trustworthy external applications (log transactions so in case of security breach it can be reverted)).

Required knowledge: PHP basics

Skill level: Basic

Mentor: Michal Hrušecký

Student: Kartik Mandaville

Blog post about karma idea

GSoC blog post about karma idea

openSUSE Build Service

OBS for Android

Mobile-apps.png

Improve and extend the mobile interface to the openSUSE Build Service. This is a mobile version of the webclient, making use of the jquery mobile framework. An Android app just wraps this interface and makes it available to the market. The current functionality is quite limited, so we should go ahead and extend it in the areas of reviewing of submit requests, displaying project build status...

Required knowledge:

Most of the required skills can also be gained by actively involving yourself during the application phase.

Please check this guide for summer of code students.

Skill level: Intermediate

Mentor: Thomas Schmidt

Student: STUDENT NEEDED.

Project wiki: Archive:GSOC 2011_OBS_Mobile

Support for Bitbake in OBS

Bitbake is class based build system. It uses .bb recipes and it is able to create rpm, deb and other formats. All from one recipe. openSUSE Build Service supports building packages on variety of distributions. Support for Bitbake would make it easier to package software and hopefully later to make it possible to build it for all distributions from one recipe. Among other tasks student would need to add support for .bb in obs, get list of dependencies from Bitbake to provide it to Build Service and create staging tree using binary packages provided by obs.

Required knowledge:

  • Python (Bitbake is written in it)
  • Shell, Perl (obs use these)
  • Basic packaging knowledge
  • Good orientation in ugly code

Skill level: Advanced

Mentor: Michal Hrušecký (feel free to replace me)

Student: STUDENT NEEDED

Blog post about this idea

Further distribution backends

The Build Service currently allows to build packages for RPM and DEB based distributions. However, adding support for futher formats (like Arch Linux) is not hard. The respective toolchain invocation has to be added to our build scripts. On top of that, new distributions have to be exposed to the user interface.

Required knowledge:

  • Package management systems (RPM, DEB), preferably those we don't support yet. Examples are Arch, MacOS, FreeBSD, Solaris.
  • Perl, for the build scripts and OBS backend bits
  • Ruby, to integrate the new features into the web user interface

Skill level: Willingness to learn new programming languages (if you don't now them yet), learn about the insights of package management.

Mentor: Sascha Peilicke (Michael Schröder would probably be more appropriate)

Student: STUDENT NEEDED

End user oriented web interface

The web interface of the Build Service is currently focused on developers. End users could benefit from exposing the work of individuals more. Displaying recent changes, a global history, activity and rating overview. Also a new user home page (similar to what Facebook or GitHub has) are ideas worth thinking about. Currently the ability to visually inspect the work of others is limited (mostly) to user's membership in projects/groups, their recent requests and what info they provide about themselves. The user's home page could be expanded by interests, external URL links (to an ohloh.net profile or blog).

Required knowledge:

  • Ruby and Ruby on Rails, to integrate the new features into the web user interface

Skill level: TODO

Mentor: Sascha Peilicke, Adrian Schröter, Markus Rückert, Thomas Schmidt

Student: STUDENT NEEDED

Creating a browser-based user interface testsuite

The Build Service API is covered by an extensive testsuite. This is similarly true for the web user interface, but with the integration of more dynamic user interface paradigms (AJAX), testing the user interface is not possible with only unit and functional testing. Therefore, a browser-based (or rendering-engine based) test-suite is needed. The student would have to investigate possible solutions (like [Selenium] based on some previous efforts into this direction and implement a testsuite on top of the results.

Required knowledge:

  • Ruby, Ruby on Rails
  • Unit testing, automated testing

Skill level: TODO

Mentor: Sascha Peilicke, The Studio team (!!!)

Student: STUDENT NEEDED

Code love for osc

Osc is a powerful tool for packaging experts, exposing all the latest and greates features of the Build Service. However, as the year's passed by it's code accumulated quite some cruft and could benefit from a rewrite of parts of it, namely it's user interface. The project would be about designing a more appropriate (EASIER) command line user interface and to implement it. Here are some ideas: Use Python argparse module for the user interface parsing and generation. Splitting of business logic that is currently found in the UI into the core parts.

Required knowledge:

  • Python, the language osc is written in
  • Experience in GUI programming and/or user interface design

Skill level: Willingness to learn new programming languages (if you don't now them yet), learn about the insights of package management.

Mentor: Sascha Peilicke

Student: Markus Hüwe would be the perfect candidate for this!


Shorter rebuild time via pre-built images

Each build is installing a system from scratch by installing packages. The built time can be improved when using pre-built images. This feature requires to be able to create images and store them on the server. Also it needs to be calculated when these images make sense and which packages they should be included.

The images can be stored back to the server or stored via LVM snapshots. (or we can use BTRFS and snapper for snapshots - http://gitorious.org/opensuse/snapper)

Required knowledge:

  • Perl
  • Bash

Skill level: intermediate

Mentor: Michael Schröder, Stephan Kulow

Student: STUDENT NEEDED

OBS Worker Management

....


Required knowledge:

  • Perl
  • Ruby on Rails
  • Some Linux internals knowledge

Skill level:

Mentor: Adrian Schröter

Student: STUDENT NEEDED

openSUSE Wubi

[Wubi] is a windows installer developed by Ubuntu that lets you install Ubuntu inside Windows. The idea is to let users install Linux without thrashing their Windows installation or without the pain of partitioning and such. Porting Wubi to openSUSE will require FAT32 support for the root partition and will require installer knowledge. It'll also require knowledge of Win32 development.

Required knowledge: C/C++ language

Skill level: Knowledge with installers is a plus.

Mentor: İsmail Dönmez

Student: STUDENT NEEDED

Bretzn

[Bretzn] is a project which tries simplify the process of bringing applications from the developers to the endusers. Part of Bretzn is a Plugin for IDEs like Qt Creator which makes it really easy to submit applications to OBS and App Stores. The second part is an App Store client which enables the end users to find and install new applications really easy. We have proof of concept implementations for all the pieces but more work is needed to integrate this further with openSUSE

Required knowledge: C/C++ language

Skill level: intermediate

Mentor: Frank Karlitschek

Student: STUDENT NEEDED

Build Service Plasma Widgets

Plasma is the toolbox which KDE builds its workspaces with. Its widgets bring information to users as part of the desktop furniture. By implementing some widgets to interface with the openSUSE Build Service you would allow users and contributors to see the status of the latest package updates or build results:

  • Package update logs
  • Request lists
  • Build results
  • Project status (packages that are outdated or not submitted to Factory)
  • Overall service status
  • Worker status/package queue size

These could be combined to form a dashboard for the parts of the OBS that a user is interested in. QML animations would make this more visually attractive than the web pages and inspire more people to use the OBS and openSUSE.

Required knowledge: JavaScript/QML OR Python OR Ruby OR C++

Skill level: basic/intermediate

Mentor: Will Stephenson

Student: STUDENT NEEDED

Distribution tools

fillup-ng

fillup is an utility, that tries to merge configuration files in intelligent way (with understanding of underlying data format). Unfortunately current implementation has some design issues that makes it hard to extend/maintain. Rewrite with modular architecture in mind is needed. Currently needed format to support is sysconfig files, but modular application ca be extended to merge ini files or xml files. Autodetection of data format would be nice feature to have, but optional.

Required knowledge: C/C++ language

Skill level: intermediate

Mentor: Michal Hrušecký

Student: Multiple students already interested

SaX 3

SaX 2 was a graphical tool for configuration of X server. It worked well with xorg.conf, but nowadays X uses mainly auto-detection and xorg.conf.d directory. But there are still cases when user needs to override automatically selected settings.

SaX 3 should be:

  • friendly tool that helps even beginners to override X settings easily
    • featuring ncurses UI for editing everything from console when you can't get your X working
    • featuring "nice" GUI (Qt or GTK) to tweak your settings if you have running X
  • dependent only on few libraries (GUI should be splittable and optional)
  • distribution independent

Required knowledge:

  • Preferably C/C++
    • other languages with no dependencies or dependencies on base system might work as well
  • Graphical and ncurses framework
    • libyui is a nice option
    • writing modular UI from scratch might be option too
  • X configuration knowledge/ability to learn it

Skill level: intermediate

Mentor: Michal Hrušecký (feel free to replace me)

Student: Manu Gupta

Blog post about this GSoC project

Make zypper search smarter

The zypper search command is rather limited in functionality and usability. First, it is not able to search for packages that match all search words, second, it sorts the result by name, while the user expects "most relevant result first" type of sorting. The idea is:

  • Implement the --match-all option and make it default (bnc#500988)
  • Search also in package descriptions by default
  • Sort by relevance
  • (optional) Search also in version strings
  • (optional) Highlight matched words in the results
  • (optional) Pipe the result through $PAGER if there are too many results

By "sort by relevance" I mean:

  • Packages with a matching name are more relevant than packages with only a matching summary or description
  • display -debuginfo, -debugsource packages at the end of the list or not at all, unless the user explicitely searches for "debuginfo"
  • give lower rank to library packages, as these provide no functionality themselves and are pulled in automatically by other packages
  • Anything else the student comes up with

Required knowledge:

  • Good in C++, some knowledge of the topic would be welcome

Skill level: intermediate

Mentor: Martin Vidner

Student: STUDENT NEEDED

Offline updade

... Required knowledge: ...

Skill level: intermediate

Mentor: none yet

Student: STUDENT NEEDED

GTK+ client for smolt

Smolt is a project that is picking stats about openSUSE installs. Currently smolt-gui developed upstream is written in Qt and it difficult to add this client to GNOME installation of openSUSE. So it's required to have a GNOME integration to ship on the default install.

It's important to have a GTK client similar to smolt-gui and ksmolt (which is the notification service launched on KDE).

Required knowledge: python or C, gtk+

Skill level: intermediate

Mentor: Vincent Untz

Student: STUDENT NEEDED

Complete spec-cleaner

spec-cleaner is a really neat tools to make sure that spec files (used to build rpm) are as clean as possible. It's currently working relatively fine, but the way it's architectured makes it hard to fix some bugs.

The project could be either to rewrite spec-cleaner with a real parser for spec files, or to improve the current code base to make it easier to add future cleaning features. The student should also add improvements (update more macros to latest versions, automatically remove old instructions that are obsolete, automatically detect missing instructions in scriptlets, etc.).

Required knowledge: python, rpm, spec

Skill level: intermediate

Mentor: Vincent Untz, Pavol Rusnak

Student: STUDENT NEEDED

Beautiful one-click-install

Garrett made a great mockup for a much more beautiful one click installer some time ago. It would be great to get this implemented. I think it could be done with a small Qt application which uses libzypp or PackageKit or something like that as the backend to do the actual installation.

Required knowledge: qt

Skill level: intermediate

Mentor: Cornelius Schumacher

Student: STUDENT NEEDED

Bug reporting tool for openSUSE

The bug reporting for openSUSE is not easy task - you have to go through all Novell projects/products, find openSUSE, assign the bug and wait until screening team will assign it to maintainer. The situation is worse with existence of various third-party repositories in BuildService. There should be tool which will help end-users with this process.

Main ideas: 

* for installed packages it can read disturl and find assignee and CC from BuildService
* it can query systems for needed information for various types of packages
* it should work from commandline - GUI is just an option

Examples: 

* [1]
* [2]
* [3]

References (not required to be derived from susereport): 

* https://features.opensuse.org/309587
* http://gitorious.org/opensuse/susereport

Required knowledge: python (most welcome, because osc and python-bugzilla are written in Python), gtk/qt (in case of GUI tool)

Skill level: basic

Mentor: Michal Vyskočil

Student: STUDENT NEEDED

Improve Clic Filesystem

Clicfs is a file system used for openSUSE live cds and is implemented as FUSE filesystem. It would be cool to have it in the kernel offering a device, that you can mount. I assume that this does not need kernel patches, but would be rather an external module.

Required knowledge: How to program linux kernel modules.

Skill level: probably high

Mentor: Stephan Kulow

Student: STUDENT NEEDED.

To learn more about clicfs, read http://lizards.opensuse.org/2009/04/28/whats-behind-lzma-compressed-livecds/ and http://lizards.opensuse.org/2009/05/06/profiled-live-cds/

YaST and libzypp/zypper

Use Augeas in YaST back-end

Augeas is a library to parse and write configuration files, using a generic mechanism driven by grammars ("lenses"). YaST has been using "agents" for this task, some of them also configurable, though in a more limited way.

Bind Augeas to the YaST library so that it can be easily used from the YCP language. Replace a couple of agents. If all goes well, do more: Replace the major agents (ag_ini, ag_any). Replace all parser agents.

Required knowledge:

  • C++ for binding Augeas to YaST (intermediate)
  • learn a little YCP (basic)

Mentor: Martin Vidner

Student: STUDENT NEEDED

Separate libyui

Libyui is a common API for Qt, Gtk and ncurses. It was developed for YaST, the SUSE installation and configuration tool.

It is still coupled to YaST too much:

  • the documentation and examples are relying on YaST infrastructure
  • it unnecessarily depends on YaST libraries
  • it is only built on openSUSE while it should work on other Linux distros

The project is to separate the library from YaST, so that other applications can benefit from having a common TUI and GUI. As a bonus the content should be improved, and a small but not trivial example application provided.

Required knowledge:

  • open source project maintenance: autotools, svn/git, doxygen, project usability (intermediate)
  • C++ (basic)

Helpful knowledge:

  • scripting languages (Ruby, Python, Perl) and SWIG, to work also on the scripting bindings for libyui

Mentor: Martin Vidner

Student: terietor and nbprashanth are applying

Use btrfs snapshots in zypper

Yum has support for doing snapshots before starting a transaction. If the transaction goes wrong, the state is rollbacked to the snapshot before the transaction. It might be a good idea to implement this feature in zypper for example using snapper - http://gitorious.org/opensuse/snapper

Required knowledge:

  • C++ (intermediate)

Mentor: MENTOR NEEDED

Student: STUDENT NEEDED

Hermes

Hermes is the central notification hub of the openSUSE Project. It gives users control over the kind of notification to receive, in which way and when.

Hermes allows users to take control of the notifications instead of being spamed automatically without having a chance to pick which information is important.

Hermes gives not only a choice which notifications are interesting for the user, but also allows to specify how the notification should be done: By email, by RSS feeds or Twitter and XMPP notifications. It furthermore can combine notifications to digest messages, for example send a combined message once an hour. Read more about Hermes.

Desktop Notifications

Hermes knows various ways of notifying, where the user can pick one. This is for example email and RSS feeds, or Twitter for special requirements.

The objective of this idea is to add another way of notification to Hermes: Desktop Notifications. Modern Desktops like GNOME or KDE use the FD.o GLALAGO spec for approaching the logged in user with news and events happening on the system. In Hermes' Starship, the user should be able to enable Desktop Notifications which results in nice integrated notifications on the desktop.


Required knowledge: Some knowledge of GNOMEs or KDEs notification system/Galago/DBus, web technology.

Skill level: Advanced

Mentor: Klaas Freitag, Thomas Schmidt

Student: STUDENT NEEDED.

Hermes Statistics for Administrators

Hermes processes thousands of notifications per day. It would be good to have some statistics about that displayed in Hermes' admin tool called Herminator useful for the Hermes administrator. It should give the administrator a good overview how the capacity is utilized and help with error detection.

Interesting statistics are

  • incoming notifications per time
  • incoming notifications per client
  • incoming notifications per time per notification type
  • number of notifications generated in relation to the incoming number of notifications
  • number of generated notifications in relation to the digest status, ie. immediately sent, minutely sent, hourly sent.
  • other interesting values.

For that, Herminator should have a statistics page and present informative graphics using RRDTools. Hermes is based on a MySQL database, so statistic data must be generated using SQL and possibly data mined into new tables.

Required knowledge: Hermes Knowledge, Perl, Perl CGI Application module, RRDTool, SQL on MySQL

Skill level: intermediate

Mentor: Klaas Freitag

Student: STUDENT NEEDED.

Custom User Message Templates

Currently Hermes generates the messages that are going out to the users from templates which depend on the message type and the media in which the message is sent. The templates are currently maintained by the Hermes Administrator.

A nice addition would be if users could create their own templates to be used instead the system ones. Furthermore, the templates should be read from the database instead of being read from the filesystem which is the current status.

That work would include

  • change the Hermes base modules to read from database instead of filesystem
  • change the Hermes base modules to prefer a user custom template before the system one
  • add the functionality to starship to enable users to edit and preview templates for their own purpose.
  • bonus: Add a functionality to propose a user custom template to the administrator to use it as system template.

Required knowledge: Hermes Knowledge, Ruby on Rails, SQL on MySQL

Skill level: intermediate

Mentor: Klaas Freitag

Student: STUDENT NEEDED.

Appliances / SUSE Studio

System to Image Migration p2i

Turn a running system into a kiwi image description. From the description a user should be able to create a clone in form of an image. There has already been some effort in this area coded as the KIWIMigrate module. This project should encourage people to enhance the code and learn about OS-images in the following area:

  • detailed inspection of the running system including check for installed software, hardware/software dependencies integrity checks and more
  • easy to understand migration report creation which provides a tasklist to the user requiring user decision
  • building images from the created image description

Required knowledge: Virtualization, kvm, perl, rpm, suse-os

Skill level: intermediate

Mentor: Marcus Schäfer

Student: STUDENT NEEDED.

One-click appliance installer for SUSE Gallery

SUSE Gallery provides something like an app store for appliances. There are lots of great appliances available for download there. But it's not always easy to actually use them, because they need some installation step, like deploying them into a virtual machine, burning them on a CD, or writing them to a disk.

Following the idea of the openSUSE one-click package installer, we could implement a one-click installer for appliances, which would be triggered by a single click in SUSE Gallery, and then do whatever is needed on the user's system to install and run the appliance.

This could be based on an extended version of the YMP format, and a dedicated client-side application, which would then deal for example with running KVM.

Required knowledge: A bit of virtualization, some client UI toolkit (e.g. Qt), some insight into HTTP APIs

Skill level: intermediate

Mentor: Cornelius Schumacher

Student: STUDENT NEEDED.

Command-line client for SUSE Studio

With SUSE Studio users can easily create openSUSE based systems in their web browser. But when running such a system, there is still missing a convenient way how to feed back changes in the system to Studio, so that with the next build on the Studio web site these changes are incorporated.

The idea of this project is to extend the Studio command line client ssc by this functionality. This could be modeled similar to how the openSUSE Build Service command line client osc works, with commands to list packages, and overlay files, to show diffs, and to commit changes back to Studio.

Find more details on the SUSE Studio command line client page.

Required knowledge: Ruby

Skill level: intermediate

Mentor: Cristian Mircea Messel

Student: STUDENT NEEDED.

Heroku like solution for SUSE Studio

Creating an appliance to run a specific rails app can be quite annoying. There are extra repositories to add, package dependencies to satisfy, a database to setup, apache and passenger to setup, overlay files to add and so on.

Cloning an appliance like this can save some time, but some efforts are still required.

IMHO the easiest solution to deploy a rails app in the cloud is Heroku.

The dister tool has been created to solve this problem.

The idea of this project is to improve dister code in order to:

  • handle complex rails app
  • support other web framework like django, cake php,...


Required knowledge: Ruby

Skill level: intermediate

Mentor: Flavio Castelli

Student: STUDENT NEEDED.

Amazon EC2 AMI creation script for Kiwi and SUSE Studio

Amazon Elastic Compute Cloud (EC2) images can now be built with SUSE Studio and Kiwi. Currently some additional steps are required to upload and create these built images to Amazon before they can be used.

The Amazon Machine Image (AMI) creation scripts developed in SUSE Studio is now open-sourced and available on Github. It currently is able to create both instance-store (S3) and EBS backed AMIs, but with separate scripts.

This objective of this project is to combine these two scripts (written in Bash) into a generic one, and to package it so that it can be integrated with Kiwi (written in Perl).

An additional objective is to extend Kiwi itself to use this integrated script for creating the actual AMIs.

Required knowledge: Bash scripting, Amazon EC2 command line tools (optional), Perl (optional)

Skill level: Intermediate

Mentor: James Tan

Student: STUDENT NEEDED.

Cross-distribution topics

The openSUSE project is proudly pushing cross-distribution collaboration.

AppStream: Make Ubuntu Software Center work on major distributions

AppStream aims to solve the topic of how to deal with installing applications in a cross-distribution way.

The Ubuntu Software Center is a great piece of software to deal with applications. Unfortunately, it's only working on Debian-based system right now.

The goal of this project is to make sure the Software Center works well on major distributions, by adding a PackageKit backend and reworking the code where needed.

Required knowledge: python, dbus

Skill level: intermediate

Mentor: Vincent Untz

Student: STUDENT NEEDED.

AppStream: Add OCS support to Software Center

AppStream aims to solve the topic of how to deal with installing applications in a cross-distribution way.

A core part of the Software Center story we want to build in AppStream is the social features: ratings, comments, etc. The open collaboration services (OCS) specification will be used for this.

The goal of this project is to implement support for OCS in the Software Center so that, at the end of the project, social features are available.

Required knowledge: python

Skill level: intermediate

Mentor: Vincent Untz

Student: STUDENT NEEDED.

Upstream/downstream tracker

Many distributions have some custom tools to track upstream, and to help determine, for example, what is the latest version of an application. However, all those tools have some limitations and none is available as a service that everybody could use.

The goal of this project is to bootstrap a common tracker that could be then used to know the status of a module upstream, but also in various distributions. Information about the versions, but also what patches distro use and opened bugs are the first metadata we'd want to cover.

Examples:

Required knowledge: preferably python

Skill level: advanced

Mentor: Vincent Untz

Student: STUDENT NEEDED.

Cross Platform Bug Tracker Client

All open source projects use a bug tracker of one kind or another. The dominant software used is Bugzilla, but many projects start off on code hosting sites like GitHub or Google Code.

There is no true cross platform open source desktop client for accessing these services. As a result of the recent HackWeek VI, a new client was created called Entomologist. It's usable right now, but there are lots of areas for improvement:

  • Port the application from Linux to OSX, Windows, or a mobile platform like Android. It compiles and runs on OSX, for example, but the UI doesn't fit very well, and desktop notifications don't work at all.
  • Add more tracker support. Currently only Bugzilla is supported, with Launchpad and Google Project Hosting on the way, but there are a lot of other trackers out there (GitHub, Trac, Savane, etc)
  • Improve the UI. Bug trackers have notoriously clunky UIs, so having a really user-friendly desktop UI would be very useful.
  • Better integration into the desktop
  • Additional features like TODO lists, private bug notes, etc.

Required knowledge: Qt/C++ and other skills depending on the specific areas of student interest (e.g, Android development, XMLRPC/REST/SOAP for adding trackers, OSX and Windows for porting, etc)

Skill level: Beginner to Intermediate

Mentor: Andrew Wafaa & Matt Barringer

Student: STUDENT NEEDED.

Testing & QA

Help to improve LTP testcases

The LTP (Linux test project http://sf.net/projects/ltp) is huge test suite that does automatic tests of Linux kernel, libc, POSIX conformance and various other parts of the modern Linux system.

There are two possibilities for improvement:

  • Test cases that are old/broken and needs to be fixed.
  • Implement new tests for parts that are not covered now.

Required knowledge: C, low level Linux (POSIX) interface, shell

Skill level: advanced

Mentor: Cyril Hrubis

Student: STUDENT NEEDED.

Create a testsuite for btrfs features

There are a couple of testsuites for stresstesting filesystem features, but it would be nice to have a testsuite which will stresstest advanced features like e.g. snapshotting. The idea is to create modular suite and implement module for testing btrfs.

The xfstests suite is a great foundation and already has btrfs tests in it already. If it is used as a foundation, it would be much more a matter of extending the existing script library, not starting from scratch.

$ git clone git://oss.sgi.com/xfs/cmds/xfstests

Required knowledge: C, low level Linux (POSIX) interface, shell

Skill level: advanced

Mentor: Greg Freemyer (Feel free to replace, I just saw a need here. I did not originate this idea, so I don't know how real the need is. I've worked with xfstests a few years ago, before it had any btrfs support at all. I have no idea what the current btrfs support level is in xfstests.)

Student: STUDENT NEEDED. Yongqiang Yang (xiaoqiangnk at gmail.com) has requested this project.

openSUSE Invis Server

The Invis Server is a so called backoffice server solution that provides small and smallest enterprises with all services they need for effective operation. The Invis Server comes with secure network management, printing, file sharing, email handling as well as fax. Moreover there are user applications like groupware, project management up to ERP software.

There is an ongoing openSUSE community effort to better integrate the Invis Server with the openSUSE distribution. The target is to provide an openSUSE Invis Server derivate which brings the whole server on one medium based on openSUSE.

Improve the Invis Portal

The Invis Server comes with a user portal which helps the users at their every day tasks such as mail, simple monitoring and such. A strong focus is put on the special user group the server is dedicated to which are mostly inexperienced computer users. The portal runs as a web application written in PHP and works mainly on the attached LDAP storage.

The task for the GSoC student is to adopt the portal application to a modern PHP framework which provides basic functionality such as authorization, theming and such. There are quite some free PHP frameworks around and the evaluation of the framework is part of the task.

The currently existing modules of the Invis Portal must be ported to the new structure, with some fixes such as internationalisation. An easy way of developing new portal modules must be designed and documented, together with a sceleton module as a starting point. Maybe one or two new modules can also be done.

Last but not least, binary packages of the Invis Portal must be built in the openSUSE Buildservice.

Required knowledge: PHP programming knowledge, interest for the small enterprise, interface design knowledge, basic binary packaging skills.

Skill level: intermediate

Mentor: Stefan Schäfer, Klaas Freitag

Student: STUDENT NEEDED

Retrieved from "https://en.opensuse.org/index.php?title=Archive:GSOC_ideas_2011&oldid=49811"