Differences between revisions 49 and 50
Revision 49 as of 2013-03-27 23:44:00
Size: 32914
Editor: ?TobiasHansen
Comment: Add project "Get Sage ready for Debian"
Revision 50 as of 2013-03-28 19:59:41
Size: 35268
Editor: HolgerLevsen
Comment: add Automated Quality Monitoring with Jenkins
Deletions are marked like this. Additions are marked like this.
Line 236: Line 236:
== Automated Quality Monitoring with Jenkins ==

 * '''Description of the project:''' [http://jenkins.debian.net]jenkins.debian.net is currently in it's infancy as a tool for the automated quality monitoring of Debian. In existence since 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 substancially improve this setup, by adding new classes of tests as well as generally improving this setup. Some examples of test classes to add:
  * 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
 * '''Co-mentors:' very welcome, also "just" for one specific test-case scenario.
 * '''Deliverables of the project:'
  * at least one new class of tests for jenkins.debian.net

 * '''Desirable skills:''' Skills that the student has or is willing to develop. Remember, the students do not have as much experience as the mentor.
  * 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 jenkins.debian.net codebase a patch 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

The main page is at SummerOfCode2013.

All the 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.


ZFS on Linux integration

  • Description of the project: ZFS provides many more advanced features than any other filesystems available to Linux users, and it's proven in production environment for years. There is btrfs under heavy development to provide similar functions, while the way is still quite long to go. At the same time native ZFS on Linux (ZoL) is a low hanging food for Linux users. To achieve this target we have two things to do: make zfs actually work on a Linux distribution; make it better integrated into the system, pushing its higher-level functions more handy to end users. This project covers the former part, which is to provide a functional ZFS support in Debian by integrating basic functions into the system and optionally d-i integration.

  • Confirmed Mentor: ?LiangGuo

  • How to contact the mentor: mail: pkg-zfsonlinux@lists.alioth.debian.org

  • Deliverables of the project: integrated ZFS on Linux support via "apt-get install"

  • Desirable skills: Familiar with Debian packaging and storage systems (RAID, HBA, iSCSI, etc)

  • What the student will learn: experience of filesystem integration and collaboration with different teams


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 or FreeSWITCH)

  • Confirmed Mentor: Daniel Pocock

  • Confirmed co-mentors: (volunteers needed)

  • 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.


One-time-password (token) based authentication and transactions

  • Description of the project: Debian now has various packages such as wheezy/oathtool and wheezy/dynalogin-server to support token authentication for various use cases. The basic use cases are UNIX logins (using wheezy/libpam-oath or experimental/libpam-dynalogin and OpenID (web based) login using wheezy/simpleid-store-dynalogin. The student will look at adding more depth in this area, here are some possible examples:

    • developing support for Challenge-Response authentication ( CROTP ) in oath-toolkit

    • developing an asynchronous AMQP-based interface for wheezy/dynalogin-server

    • enhancing wheezy/simpleid to create user profiles on the fly

    • using some combination of these technologies to enable a more secure experience with digital currency transactions (e.g. for Bitcoin)
  • Confirmed Mentor: Daniel Pocock

  • How to contact the mentor:

  • Confirmed co-mentors: other members of the pkg-auth team

  • Deliverables of the project: to be identified in consultation with the mentor(s)

  • Desirable skills: C, C++, Java, PHP, cryptography

  • What the student will learn: becoming experienced in UNIX security, distributed authentication systems for the web and potentially even systems for authorisation of electronic payments


PTS rewrite in Django

  • Description of the project: the Package Tracking System (PTS) is the main, source package-centric portal for Quality Assurance and package monitoring in Debian. It is widely used and in good shape. However, the technology it has been built upon is starting to show its age; also, the PTS currently uses a wide range of technologies (Python, Perl, shell script, XML, XSLT, ...) making it more hard to hack on than needed, in particular if you consider which technologies are nowadays popular in the Debian community. Finally, the current design of the PTS is entirely static, with refreshes occurring 4 times a day. That is good for performance, but it is a blocker for making the PTS a "live" data monitor and makes it unnecessarily hard to scale up to more frequent data updates. The content is also very Debian-specific and makes it unnecessarily difficult to setup a PTS instance for a Debian derivative for example. A more modular approach should be possible. This project aims at providing a new, alternative implementation of the PTS, using technologies that are popular in Debian (Python + Django), and getting rid of blockers for future evolution of the PTS, most notably the ability to provide live updates and to customize the content by enabling/disabling modules.

  • Confirmed Mentor: Raphael Hertzog (PTS original author and long-time maintainer)

  • How to contact the mentor: hertzog@debian.org

  • Confirmed co-mentors: StefanoZacchiroli

  • Deliverables of the project:

    • drop-in PTS replacement written in Python using the Django web framework. It should be possible to run the new implementation locally, obtaining pages (and features, most notably: mail subscriptions) equivalent to the current ones.
    • Time permitting, some scalability assessment might be desirable. It's to be expected that parts of the dynamic content should be cached (using Django's cache feature) to provide a good compromise between freshness and performance.
  • Desirable skills:

    • experience in Python+Django development
    • familiarity with the PTS current implementation
    • please include as part of your application a patch to the current PTS code that adds a bullet with your name under the "todo" section of each package page

  • What the student will learn: developing a large and popular dynamic web application; migrating an existing and in production code base to an alternative implementation; (time permitting) doing performance assessments of static vs dynamic websites


OpenJDK and Debian

  • Description of the project: The goal of this project is double. The first step would be to finalise the transition to the OpenJDK 7. This means managing with the mentor a full rebuild of the Debian archive on the Amazon cloud with the OpenJDK. Then, fix the various build issues. The second step will be to package the OpenJDK 8 and perform the same tasks.

  • Confirmed Mentor: Sylvestre Ledru

  • How to contact the mentor: sylvestre@debian.org

  • Confirmed co-mentors: Welcome

  • Deliverables of the project: Jessie based on the OpenJDK 7, a proof of concept for OpenJDK 8

  • Desirable skills: Debian / Ubuntu packaging experience

  • What the student will learn: The OpenJDK packaging, Java packaging, interacting with the Debian community, etc

  • Expected from the student: Please provide a patch fixing a build failure of a Java package built with the OpenJDK 7


scan-build on the Debian archive

  • Description of the project: scan-build is a program provided in the clang package. It provides an excellent static analyzer for C, C++ and Objective-C code. It can find bugs that a compiler cannot find, providing a visual report. Example: http://scan-build.scilab.org/. The goal of the project is to rebuild the whole Debian archive using scan-build, extracting the report and publishing them on a common interface (daca?).

  • Confirmed Mentor: Sylvestre Ledru

  • How to contact the mentor: sylvestre@debian.org

  • Deliverables of the project: A website with reports of all Debian packages with scan-build errors

  • Desirable skills: Debian / Ubuntu packaging experience, pbuilder

  • What the student will learn: Compilation procedure, static analysis

  • Expected from the student: A scan-build report of a Debian package with the procedure to perform it


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 programming
    • Python libraries: some Python templating engine (e.g. genshi, jinjia2, etc.) for the static part; Django for the dynamic part

    • knowledge of matplotlib for the graph generation part

    • please include as part of your application a Python program that uses matplotlib 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


Leiningen & Clojure packaging

  • Description of the project: Leiningen is a Clojure project automation tool, used by the vast majority of Clojure projects. If we want to have Clojure libraries and applications packaged for Debian, we need Leiningen too. However, packaging leiningen is far from a trivial tasks: all the dependencies need to be packaged too, for one. And it becomes useful only when packages that need leiningen will become easier to package aswell. Therefore, the goal of this project is two-fold: package leiningen and its dependencies, and write tools (like dh_lein2) that will make it either fully automate parts of the clojure packaging process, or at worst, make it considerably easier to do. This is a required step to have a usable Clojure ecosystem within Debian.

  • Advocate: Gergely Nagy

  • Confirmed Mentor: Wolodja Wentland (debian@babilen5.org; babilen on IRC), Gergely Nagy (algernon@debian.org; algernon on IRC)

  • How to contact the mentor: You can mail each of us or pop into #debian-clojure on irc.oftc.net

  • Confirmed co-mentors: Paul Tagliamonte (paultag@debian.org; paultag on IRC)

  • Deliverables of the project:

    • Leiningen2 and dependencies packaged for Debian
    • A tool that helps packaging Clojure projects that depend on Leiningen easier (along the lines of dh-make)
    • A tool that helps building and assembling the debianised package (dh_lein2)
    • Documentation about the tricky bits of Clojure packaging, common pitfalls, and things to pay extra attention to.
  • Desirable skills:

    • Reasonable knowledge of the Clojure language, tools and ecosystem
    • Familiarity with Java, maven in particular is highly recommended
    • Basic knowledge of Debian packaging (if you know what debhelper is, you're good)
  • What the student will learn:

    • A lot about Debian packaging, and about writing tools to aid packaging
    • The dark corners of the Clojure and Java ecosystems
    • The difference between the Clojure/Java and Debian packaging philosophies


MIPS N32/N64 ABI port

  • Description of the Project: This project attempts to create a new MIPS N32/N64 ABI port for Debian. Different from O32, N32 is an address model that has most 64-bit capabilities but uses 32-bit data structures to save space and process time. N64 is a full 64-bit address model. Multiarch support is almost available in Debian, though its bootstrap and cross build is still on the way. We are able to apply the state-of-art technology to help during bootstrap. 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: AronXu

  • How to contact the mentor: E-mail: debian-mips@lists.debian.org (TBD)

  • Deliverables of the Project: A running mips64el sbuild with chroot. It is also desirable to have similar setups for mipsn32el and non-el variants.

  • Desirable Skills: Familiar with base system environments and some knowledge of C/C++.

  • What the Student Will Learn: Experience of bootstrapping on a new architecture port from scratch.

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


A cloud image for bioinformatics with Debian

  • Description of the project: This is a call for bottom-up proposals structured by students themselves along the following lines. 2012 has been a year of progresses in Debian's support for clouds. Combined with Debian's leadership in the distribution of packaged scientific and medical software, this opens opportunities for establishing Debian as a first-class provider of virtualised solutions for bioinformatics. To be successful, proposals will need to go beyond simply booting a Wheezy image and typing apt-get install med-cloud, and take into account the prior art of Cloud Bio-Linux, which is already distributing our packages in cloud images. They will have to address other problems, such as the need for precise versions of software, the need for images that will happily crunch hundreds of gigabytes of data, the need for parallelisation of workflows, etc. The project's deliverable must be useable on Free platforms, and the proposal needs to explain which infrastructure will be used during the development.

  • Potential mentor: CharlesPlessy, other mentors welcome.

  • How to contact the mentor: mail: debian-med@lists.debian.org or debian-cloud@lists.debian.org

  • Deliverables of the project: Bioinformatics with Debian on the Cloud

  • Desirable skills: Familiarity with virtualisation, cloud environments, or scientific computing are a good start.

  • What the student will learn: Depending on the contents of the proposal, the student will learn about the Debian system and its installation, about the Debian Blends, and about the Debian infrastructure.


Redesign metapackage creation for Debian Blends

  • Description of the project: In Debian Blends a basic way to install packages belonging to a certain user task is a set of so called metapackages. These metapackages are created by using so called tasks files as data input specifying dependencies from binary packages. The package blends-dev contains tools to create a Debian source package which has set all dependencies according to the specification inside the tasks file which are validated against the packages inside the package pool. This ensures that the resulting metapackages will install nicely into a system that is up to date at the time of creation of this source package. Currently blends-dev is verifying the package pool of the architecture on that the source package is created (when blends-dev is called). In practice this has the effect that the most popular architectures (i386, amd64) are used as reference for metapackages which are intended to work on all available Debian architectures. Strictly speaking this is wrong even if there is no known case were this has leaded to practical problem. An additional source of information to create metapackages could be to use the information of Debtags. Currently the maintenance of Debtags and tasks files is independent from each other but this does not necessarily need be the case. There could be ways to either synchronise the information or at least regard both sources of information into account when creating metapackages. The task of the GSoC project is to rewrite the blends-dev code to enable architecture dependent metapackages.

  • Hint for solving this task: It seems to be the best way to use the UltimateDebianDatabase (UDD) to obtain the relevant information. The UDD is a commonly used resource in Blends (see other GSoC project) and provides a very handy access to the necessary information about binary packages. Because the implementation is very different than the current code the task is basically programming from scratch and thus the prefered programming language for this task would be Python (the current code is in Perl for historic reasons).

  • Confirmed mentor: AndreasTille

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

  • Deliverables of the project: Procedure to create Blends metapackages for all supported architectures

  • Desirable skills: SQL, Python

  • What the student will learn:


Enhancing Debian Blends web sentinel

  • Description of the project: A very important feature of Debian Blends is the so called web sentinel currently featuring so called tasks (example) and bugs (example) pages. It has turned out that several (want-to-become) Blends could profit from the data gathered for this purpose to create their own dedicated views on the package pool. The option of some easily accessible information in some intermediate format (json) would help a lot to make even more use of the information that currently is assembled in the web sentinel. The current code makes heavy use from UltimateDebianDatabase (UDD) queries but is not very friendly regarding a simple json output. So the task would be to reuse the querying code to assemble the needed data but define a new data structure that fits into a reasonable json format. As a second step sentinel pages - in the optimal case enhanced in style and functionality - should be created from the json format. Furthermore get in contact to other projects like NeuroDebian for other output formats. Some option for user feedback on the pages would be quite interesting to have. You need to keep in mind that the tasks pages are translated into several languages - in principle we could use any translation that is used for Debian package descriptions. Currently this is implemented in static pages in the same way as www.debian.org is doing translations. If you consider some web publishing tool which might be nice and shiny but does not have the easy feature of supporting all those translations - please forget it. Translations are important and it is not acceptable to drop this feature. The tasks pages are providing direct connections to

  • Confirmed mentor: AndreasTille

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

  • Deliverables of the project: Web sentinel for Blends; easily accessible database containing all information about Blends packages

  • Desirable skills: SQL, Python, JSON

  • What the student will learn:

    • becoming comfortable with the idea of Blends
    • learn to know very different sources of information inside Debian (UltimateDebianDatabase, Debtags, etc.)

    • work together with several teams inside Debian


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

  • 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.

Automated Quality Monitoring with Jenkins

  • Description of the project: [http://jenkins.debian.net]jenkins.debian.net is currently in it's infancy as a tool for the automated quality monitoring of Debian. In existence since 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 substancially improve this setup, by adding new classes of tests as well as generally improving this setup. Some examples of test classes to add:
    • 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

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

  • Deliverables of the project:'

    • at least one new class of tests for jenkins.debian.net
  • Desirable skills: Skills that the student has or is willing to develop. Remember, the students do not have as much experience as the mentor.

    • 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 jenkins.debian.net codebase a patch 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

Projects without confirmed mentors

This page contains project ideas, with advocates, but without confirmed mentors. These projects won't happen if nobody steps up to the task of mentoring them.

If you are willing to mentor one of those projects, please add your name to the Mentors section and move the paragraph back up the the first section.

If you want to add an idea, please follow the template below. But before doing so, please consider mentoring the project, and/or looking for co-mentors to help you doing so. Not having mentors means the project won't happen.


Framework to manage lists with third parties on the Debian website

  • Description of the project: Debian maintains on its website several list with contacts of third parties related in some way to Debian (CD vendors, consultants, users, system integrators, etc.). These lists are currently maintained by hand, in various formats and methods, in most cases by editing the webwml source directly. This is tedious, boring and error prone work. New submissions, changes or removals should probably happen via some form, more or less automatically (depending on whether additional checks and approvals are needed or the automatic validity checks are enough). Also some more or less automated periodic quality checks would be required, like checking the validity of submitted URLs and e-mail contacts. Some of these tasks have similarities to a mailing list manager.

  • Advocate: AndreiPopescu

  • Potential mentor: To be determined

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

  • Deliverables of the project: automated and unified system to manage submissions/changes/removals for all lists of third parties on the Debian website

  • Desirable skills: webwml, scripting language (probably Perl or Python)

  • What the student will learn: creating a database management system that accepts input fron non-trusted parties, with as little human interaction as possible (or desired).


Debian-Installer OEM image creator

Description of the project

The idea is to create an "OEM-creator" script/program, that would produce a dd'able image containing a nicely-configured debian-installer that could serve two purposes:

  • Initial installation support
  • Rescue image
  • (Partial stable mirror for the given architecture.)

This image would be a ~1Gb partition with all packages needed for the targeted install.

The script must be able to:

  1. trustfully download the necessary hd-media files
  2. create the preseed (and the necessary GRUB-2 configuration)
  3. "pack" everything into a dd-able image
  4. [optional] "pack" the image at point 3 into a base CD/DVD image to automatically install the OEM-image on an HD

This script could make a good use of Ubuntu's OEM mode, which would then need to be properly integrated in d-i.

Alternative idea

Add support to dpkg/apt/debootstrap/d-i and maintainer scripts for a "generically configured" state that packages could be in. This would be less hacky than current methods for live/preinstalled image production.

Initial installation

This would be the first thing booted on a fresh machine, launching a preseeded d-i that would offer the minimum amount of questions, installing machine-specific packages such as (proprietary) drivers, install what else the hardware manufacturer would have liked to, etc.

The preseed would by default "protect" this partition from being erased or updated.

Documentation

Mentoring

  • Confirmed Mentor: To-be-discussed

  • How to contact the mentor: mail, IRC

  • Confirmed co-mentors: DidierRaboud (I'm not willing to mentor that on my own and would rather have other co-mentors on board)

  • Deliverables of the project: Either patches to debian-installer's ecosystem to produce a new set of "OEM" images, or a script/tool to create these from standard debian-installer images.

  • Desirable skills: moderate Debian knowledge, scripting skills, good communication and debating skills

  • What the student will learn: The student will learn how to design, develop, test and integrate a big project within one of the core Debian softwares: the debian-installer. In the process, the student will acquire lots of knowledge around the low-level computers' infrastructures and, more generally, everything the Debian-Installer touches. Good design and developement practices will be acquired, along with scripting and programming skills in the chosen language

Debian Android Application

  • Description of the project: Debian Developers utilize many online resources on a daily basis in order to properly maintain their packages. Some of these tools include the PTS, BTS, and UDD. It would be nice to have all of this information readily available on a phone/tablet via an android application. The application would use existing Debian APIs to fetch and display all of the information. For things like the BTS, it might support functionality similar to reportbug.

  • Confirmed Mentor: To-be-discussed

  • How to contact the mentor: To-be-discussed

  • Confirmed co-mentors: To-be-discussed

  • Deliverables of the project: The ideal final result of this project would be an Android application that is either distributed via the Google Play store (for free) or available for download from a Debian website.

  • Desirable skills: Android Application Development, Java

  • What the student will learn: Students will gain experience with the many tools Debian Developers utilize on a daily basis, which will prove useful if they decide to become a Debian Maintainer/Debian Developer in the future.