Differences between revisions 128 and 129
Revision 128 as of 2013-10-23 05:30:34
Size: 19706
Editor: ?BrianGupta
Revision 129 as of 2013-10-23 05:31:19
Size: 19619
Editor: ?BrianGupta
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
---- /!\ '''Edit conflict - your version:''' ----
The main page is at SummerOfCode2013 and coding projects for OutreachProgramForWomen.

/!\ '''End of edit conflict''' ----
The main page is at SummerOfCode2013 and OutreachProgramForWomen. (Depending on your program)

The main page is at SummerOfCode2013 and OutreachProgramForWomen. (Depending on your program)

Project template

All the project descriptions should follow the following template.

Title of the project

  • Description of the project: At least 8-10 lines describing what the project is about; it is really important to have a good description if you want to attract students who are interested by the idea. This does not need to be a very technical description, but something that stirs interest and is complete enough to allow a student to judge whether s/he wants to work on the particular project or not. It does not need to be a complete road map either and does not need to explain all the tiny details and whatnot -- the mentor can tell that to interested students, or they can work out the exact details together.

  • Confirmed Mentor: Name of the mentor

  • How to contact the mentor: (mail, IRC, etc)

  • Confirmed co-mentors: It is not compulsory to have co-mentors, but it is a good idea. Secondary mentors do not need to be as knowledgeable as the first one in the project, but they should be available to help the student if s/he is stuck and the main mentor is busy / not available.

  • Deliverables of the project:

  • Desirable skills: Skills that the student has or is willing to develop. Remember, the students do not have as much experience as the mentor.

  • What the student will learn: At least 2-3 lines telling the students the skills they develop and how they will improve Debian. Do not focus on the technologies, rather use something that could motivate the prospective student to take your project.

Projects with confirmed mentors

Please keep this section clear of project ideas without confirmed mentors, to avoid any confusion for prospective students. Such projects should be published in the next section.

Test suite for Debian's archive management software (dak)

  • Description of the project:

    • The software managing Debian's archive (ftp.debian.org) currently has no test suite. This means there is no automated way to check that changes don't introduce regressions. Large parts of dak are dependent on the current state of the archive, so simple unit tests will not help in many cases. The goal of this project is to develop a framework for running tests and implementing such tests. To make sure tests are repeatable, they should be run in a clean installation. So automatically setting up an installation might also be a required part of the project.

      See http://lists.alioth.debian.org/pipermail/soc-coordination/2013-March/001408.html for a bit more detailed description.

  • Confirmed Mentor: Ansgar Burchardt

  • How to contact the mentor:

  • Confirmed co-mentors: Jörg Jaspert

  • Deliverables of the project: Infrastructure to develop and run tests for dak and some such tests.

  • Desirable skills: Python, PostgreSQL, creating Debian package (just basics).

  • What the student will learn: Besides planning and developing a test suite, students will get a view into the infrastructure running Debian's archive.

Debian metrics portal

  • Description of the project: To improve, one needs to measure, apply changes, and see how the changes affect the observed quality. In Debian, we have a lot of project-wide metrics, Statistics, and graphs. Unfortunately they are scattered and maintained in a non-coordinated manner, resulting in recurrent shortages, and the lack of a uniform interface to view, add, and query Debian metrics. This project aims at building a Debian metrics portal with a uniform (Web) interface to peruse Debian metrics, as well as a uniform (programming) interface to maintain them.

  • Confirmed Mentor: StefanoZacchiroli

  • How to contact the mentor: see mentor wiki page

  • Confirmed co-mentors: none yet

  • Deliverables of the project:

    • standardized interface to add/remove metrics to be graphed (possibly with different sampling rate)
    • integration of existing graphs in the metrics infrastructure
    • web interface to show daily (or more frequently) updated graphs of the various metrics
    • dynamic web interface to graph, on demand, specific metrics (possibly more than one at a time) over specific time periods
    • (optional) package the developed code to ease deployment on Debian-based machines
  • Desirable skills:

    • Python

    • RRDtool and its Python bindings

    • some Python templating engine (e.g. genshi, jinjia2, etc.) might be useful
    • some ?JavaScript library to generate dynamic graphs might be useful as well (name one!)

    • please include as part of your application a Python script that uses RRDtool to graph some of the metrics from UDD history table

  • What the student will learn: deal with live legacy data and code; consolidate into a single, well-designed architecture existing functionalities; this will help Debian in monitoring its strength and deficiencies, and evaluate the usefulness of changes to project processes

MIPS N32/N64 ABI port

  • Description of the Project: MIPS is one of the most elegant RISC CPUs in the industry, and there are quite a lot different usages in its family. This project attempts to create a new MIPS N32/N64 ABI port for Debian. Different from O32 (used by existing mips/mipsel port), N32 is an address model that has most 64-bit capabilities but uses 32-bit data structures to save space and process time, it is quite similar to the ongoing x32 port for x86 platform. At the same time, N64 is a full 64-bit address model which is comparable to x86_64 on x86. There is consensus that N32/N64 ABI would give capable devices better performance, while O32 ABI should be kept for devices that is only 32-bit capable. Since Multiarch support is almost available in Debian, we are able to apply the state-of-art technology to help us on both bootstrapping and future usages. Users can run N64 kernel with mixed N32/N64 userland to take advantage of both the performance and the large memory as needed.

  • Advocate: AnthonyFok

  • Confirmed Mentor: YunQiangSu

  • Confirmed co-mentors: ?ZhangLe (r0bertz AT gentoo.org), ?DavidDaney (david.daney AT caviumnetworks.com), ?YanHua (yanh AT lemote.com)

  • How to contact the mentor: mail: debian-mips@lists.debian.org

  • Deliverables of the Project:

    1. Cross toolchains on at least amd64 for mips64 and mips64el systems.
    2. Running sbuild instances with mips64 and mips64el chroots (build-essential), resolve outstanding porting issues getting in the way of satisfying build-essential.

    3. Do a try build of the archive, attempting to meet the requirement of uploading to debian-ports.org. This could be limited by the performance of available developer box thus not required to cover 100%.
    4. A performance comparison of O32, N32 and N64 ABIs.
    5. It is also desirable to have similar setups for mipsn32 -el and non-el variants.
  • Desirable Skills:

    1. Familiar with base system environments.
    2. Some knowledge of C/C++ and debugging.
    3. Good understanding to what is Multiarch and how it works.
  • What the Student Will Learn: Experience of bootstrapping on a new architecture port from scratch.

  • References: mips64/mips64el n32 port discussion bootstrap docs.

  • Additional notes : When writing for applying to the project, please tell us your plan on how to do the comparison of performance among different ABIs? Also please give a simple example on doing the mesurement for the i386 and x32 architectures, or amd64 and x32 architectures.

Get Sage ready for Debian

  • Description of the project: The mathematics software system Sage is currently shipped and built together with all its dependencies. Linux distributions package the dependencies separately (mainly done in Debian, see Wiki page) and want to obtain from the Sage website only Sage itself. The Sage build system currently only supports using all dependencies bundled with Sage. The idea is to enhance the Sage build system to accept a list of dependencies, for which the version provided by the OS is used instead of the bundled one. Given that Sage robustly supports this scenario, it will not be difficult to create a Debian package of Sage.

  • Confirmed Mentor: Tobias Hansen (Debian)

  • How to contact the mentor: thansen@debian.org, thread on sage-gsoc

  • Confirmed co-mentors: Jeroen Demeyer (Sage), John Palmieri (Sage), Julien Puydt

  • Deliverables of the project:

    • support in Sage for choosing a set of dependencies that are satisfied by the OS instead of using the bundled version
    • a Sage Debian package
  • Desirable skills: familiarity with build systems (e.g. Makefiles/autotools/SCons/distutils), Python, shell scripts and C libraries

  • What the student will learn:

    • managing a compilation of a large, heterogeneous set of software components to create a user-friendly product
    • The student will gain equal amounts of insight into the inner workings of both a Linux distribution and an upstream software project.
  • Note regarding the project proposal:

    • When submitting a proposal for this project, specify Sage as the mentoring organization. This project is also on the Sage idea page.

Automated Quality Monitoring with Jenkins

  • Description of the project: jenkins.debian.net is currently in its infancy as a tool for the automated quality monitoring of Debian. In existence since the end of 2012 it currently does three major things: a.) debootstrapping of various distros in a chroot and then installing common package sets b.) installation tests with debian-installer, producing a video of the installation, again for various suites and desktops (as well as Debian Edu profiles) and c.) builds on every SVN/GIT commit of debian-installer components, manual translations as well as webchecks.

  • The goal of this project would be to substantially improve this setup, by adding new classes of tests as well as generally improving things. Some examples of test classes to add (see TODO in git for more ideas):
    • run autopkg-tests for packages which have them and create jenkins jobs automatically when autopkg-tests are added to a package
    • d-i: build image on every commit and test it with g-i
    • build packages from all team repos on alioth with jenkins-debian-glue on team request (eg, via a .txt file in a git.repo) for specific branches (which shall also be automated, eg. to be able to only have squeeze+sid branches build, but not all other branches.)
  • Confirmed Mentor: Holger Levsen

  • How to contact the mentor: holger@debian.org or debian-qa@lists.debian.org / #debian-qa on IRC

  • Co-mentors: very welcome, also "just" for one specific test-case scenario.

  • Deliverables of the project:

    • at least two new classes of tests running on jenkins.debian.net
  • Desirable skills:

    • familar with shell and python (all the current test cases are written as bash scripts and for Job creation and configuration jenkins-job-builder is used, which is written in Python.)
    • knowledge of Jenkins and Debian procdedures
    • please include as part of your application a patch to the current codebase which adds a jenkins job which checks whether wheezy has been released. Alternativly provide a patch which removes redudancy in job-cfg/*.yaml

    • What the student will learn:

      • how to automate tests with Jenkins
      • how Debian is made and how it can be made better

Package cross-building continuous integration

  • Description of the project: Cross-building support has become important as ARM development has become a major focus, but fast ARM build hardware remains rare. A lot of core work has been done to make this a reality in Debian, with multiarch and improved toolchain support. But most package maintainers are not aware of this, nor of the status of their packages. And many, many packages remain to be fixed. Continuous cross-build testing of packages and reporting the status in the Package Tracking System (http://wiki.debian.org/qa.debian.org/pts) would enable distribution of the large task of making this work everywhere.

  • This needs cross-build infrastructure to be set up and integrated. A cross-aware buildd running cross-builds of new uploads for multiple target architectures, scripts to deploy such instances on (virtual) servers, PTS integration, web UI reporting current status and regressions. Many of the parts for this already exist to some degree, but code is needed for buildd cross-awareness, deployment, PTS and UDD integration and regression reporting. As well as an infinite amount of actual cross-build bug-fixes.
  • Confirmed Mentor: Wookey

  • How to contact the mentor: wookey@wookware.org, wookey on #emdebian, #mulitarch on oftc.net

  • Deliverables of the project: A continuously running cross buildd reporting status into the debian Package Tracking System.

  • Desirable skills: Debian cross-build mechanisms (https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingMultiArch), soap/LDI, scripting languages (perl/shell/python)

  • What the student will learn: The importance and practicalities of continuous integration testing. Integrating code across multiple subsystems. How build daemons work

Enabling free multimedia real-time communications (RTC) with Debian

  • Description of the project: Debian contains various applications for RTC, including softphones, SIP proxies, XMPP/Jabber servers and full soft PBXes such as Asterisk. Unfortunately, users continue to report problems getting them to all work together. A typical complaint is that user A can only call user B if using the same softphone, same version, and on the same LAN. Modern IETF standards such as ICE/STUN/TURN are supposed to enable successful calling across NAT/firewalls, much like with proprietary softphones. Debian has the foundations for this (see packages reTurn and sid/turnserver) but more work is needed to make a turn-key solution based on Debian that is convenient for mass deployment. The project could involve some combination of the following activities, based on the interests and capabilities of the student:

    • setting the benchmark for Debian 8.0: defining the RTC experience that Debian should promise to the Debian community (e.g. what level of convenience and interoperability guarantees should we offer for Debian 8.0 and beyond),
    • looking at the role of next-generation solutions, e.g. WebRTC and mobile VoIP
    • measuring the capabilities of existing and potential packages against the benchmark,
    • setting up continuous integration or test environments to provide ongoing, automated interoperability testing for key packages within the testing and unstable environments

    • identifying and implementing any quick wins: e.g. packages that only need minor patches or configuration changes to enjoy significant improvement
    • identifying at least one more detailed project: a new package or significant improvement to an existing package that will bring significant benefit (e.g. packaging of Jitsi, SylkServer conferencing, FreeSWITCH or Linphone)

  • Confirmed Mentor: Daniel Pocock

  • Confirmed co-mentors: (volunteers needed, contact Daniel)

  • Deliverables of the project: contribution to a strategic roadmap for RTC in Debian. Improvement or addition of at least one package in such a way as to help fulfill the strategy.

  • Desirable skills: any one or more of the following: C, C++, Java, SIP, XMPP, JavaScript/HTML5/WebRTC, Android

  • What the student will learn: the student is likely to become an expert in developing fields like WebRTC and is likely to end up knowing more about these fields than many existing developers.

Improving free financial software packages

  • Description of the project: There are a range of financial packages in Debian now, including PostBooks and GnuCash. There are many opportunities to make these packages easier to use for the Debian community. Many Debian users are IT workers, freelance workers, consultants and contractors. This type of user needs to use the software for a few hours per month to track their credit cards and make invoices for their customers. Some possible projects:

    • Some of the software has a strong emphasis on the US market, one possible project would involve making the software easier for European users.
    • Using a format such as cXML to exchange invoices between two of the open source accounting programs.

    • Automating ?BitCoin payments from one of the accounting programs

    • developing an open source feed handler for OpenMAMA (this project would be good for somebody who wants to do low latency network programming) - see this blog for detail about the API

    • adapting other packages (e.g. PostBooks, GnuCash, shopping cards), to read live exchange rates from OpenMAMA

  • Confirmed Mentor: Daniel Pocock

  • How to contact the mentor: daniel@pocock.com.au

  • Confirmed co-mentors: to be confirmed (potential co-mentors please contact Daniel)

  • Deliverables of the project:

    • Patches against one or more of the open source accounting programs
  • Desirable skills:

    • At least one programming language of C, C++, Java, ?JavaScript

    • Knowledge of SQL, PostBooks uses PostgreSQL

    • basic knowledge of double-entry accounting.

    • Experience with Qt or another C++ GUI framework would be very useful too, but not essential
  • What the student will learn: experience of the basic business accounting processes that are used in every type of business around the world from private consultants up to international companies.