Differences between revisions 23 and 24
Revision 23 as of 2013-03-11 19:25:59
Size: 16607
Editor: SukhbirS
Comment: only one student is allowed per project
Revision 24 as of 2013-03-11 22:13:17
Size: 18632
Editor: ?algernon
Comment: Added a Leiningen & clojure packaging project
Deletions are marked like this. Additions are marked like this.
Line 169: Line 169:

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

(Do note, that this is a draft for now, and will be slightly improved upon in the near future)

 * '''Advocate''': Gergely Nagy
 * '''Confirmed Mentor''': To be determined.
 * '''How to contact the mentor:'''
 * '''Confirmed co-mentors:''' Gergely Nagy (algernon@debian.org; algernon 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

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

  • How to contact the mentor:

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


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: Stefano Zacchiroli (PTS long-time co-maintainer), contact: zack@debian.org

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


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.


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.

  • Advocate: CharlesPlessy

  • Potential mentor: To be determined.

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


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


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: To be determined.

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

  • Confirmed co-mentors: To be determined.

  • Deliverables of the Project: A running mipsn32el sbuild with chroot. It is also desirable to have similar setups for mipsn64el 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.


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


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.

(Do note, that this is a draft for now, and will be slightly improved upon in the near future)

  • Advocate: Gergely Nagy

  • Confirmed Mentor: To be determined.

  • How to contact the mentor:

  • Confirmed co-mentors: Gergely Nagy (algernon@debian.org; algernon 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