SBR600 Potential Projects

This is a draft only!
It is still under construction and content may change. Do not rely on this information.

Old Version
This list has not yet been revised for the Winter 2011 semester.

Introduction

This is a list of potential projects related to the SBR600 course that need people.

Students: Please select a project that you're interested in and add an entry to the project table/participants page.

Open Source Community Members: We welcome your recommendations for potential projects. Please create an account on this Wiki and create a description for your proposed project below. Please list your contact info (just an IRC or FAS2 name is OK) as well as links to any related web pages as Resources for the proposed project. (Questions? Ask Chris Tyler).

Sample Project

This is a sample project stub. You can use the template for Sample Project in order to create a project page for one of the stubs below. This is how you 'sign-up' for a project.

NOTE: if someone has already created the project page, speak to this person and see if you can join them. If so, simply add your name to the Project Leader(s) page. Otherwise, you can become a contributor later.

Fedora-ARM Projects

To Thumb or Not To Thumb?

The core of all ARM processors are designs licensed from ARM Ltd. There are several different architecture versions; Fedora-ARM targets the armv5tel architecture as a "lowest common denominator" among current ARM chips. This architecture supports a thumb instruction set, which uses 16-bit instructions instead of 32-bit instructions, leading to a higher code density.

Fedora-ARM does not use thumb. The purpose of this project is to discover whether thumb provides any significant savings in terms of code size, whether programs compiled to thumb execute more quickly or more slowly than non-thumb programs on common ARM processors, whether a thumb compilation takes more or less time than non-thumb, and whether there are any other factors that would influence the decision to support thumb. Ultimately, this project should make a recommendation on the use of the thumb instruction set for the Fedora-ARM secondary architecture.

Initial contacts: ctyler, PaulW

Supporting Architectures Above armv5tel

The armv5tel architecture version is supported by some common devices such as the Marvell Feroceon processors used in most plug computers. However, later versions of the architecture support advanced features, and using armv5tel code on those processors may result in suboptimal performance.

This project will research ways that Fedora-ARM could support higher processor versions effectively without recompiling the entire Fedora package universe -- for example, by providing an armv7 + hardfp glibc and kernel. This involves performance testing across multiple devices.

Initial contacts: ctyler, PaulW

Fedora-ARM Dogfood - Koji Hub

The Fedora-ARM koji system uses HongKong, an x86_64 system, as the Koji hub, along with a group of ARM builders.

Ideally, it would be nice to prove the ability of the Fedora-ARM project to be entirely self-hosting by using an ARM system as the Koji hub (this is sometimes called "Eating your own dogfood" in the industry). This project involves configuring the OpenRD-Client system as Koji hub.

Initial contacts: ctyler, PaulW

Set up Nagios monitoring for the ARM farm

Nagios is a system monitoring tool; setting it up for the Fedora-ARM build farm will make it easier to get timely notification of system issues.

Initial contacts: ctyler, PaulW

Set up Puppet

Puppet is a tool for managing configuration files. It should be set up on the Fedora-ARM build farm so that configuration files can easily be deployed across the entire farm.

Initial contacts: ctyler, PaulW

Set up FUNC

Func is the Fedora Unified Network Controller -- a way of controlling a group of machines en masse. We need FUNC set up for the Fedora-ARM build farm.

Initial contacts: ctyler, PaulW

Device Support and Testing

Various ARM devices need different driver sets and/or kernels. This project will test the Fedora-ARM system on various devices and create a collection of kernels and/or initrd images, and possibly a repository of non-free device drivers to complement the open source device drivers provided by Fedora. It will also involve creating documentation for the setup for various boards and devices.

Initial contacts: ctyler, PaulW

Fedora Projects

fedpkg Test Suite

fedpkg is a new Fedora packager tool written by Jesse Keating; it's one of the main command-line tools that a packager will use. It needs a test suite, so that as new features are added, regressions can be detected.

Initial contacts: Oxf13

Koji Setup Documentation

Koji documentation is obsolete and needs a major overhaul. This project involves reading the current documentation, updating and editing it, and testing it by setting up a Koji system.

Initial contacts: ctyler, dgilmore

AutoQA

AutoQA is an automated test system for Fedora. At present there are event watchers for koji builds, bodhi updates, repo changes, and nightly installed images; these events trigger a small number of tests, but more tests are needed.

Initial contacts: JLaska

Fedora-Mozilla Projects

Repository Setup for Mozilla Nightlies and Betas

Many web developers want access to the latest Firefox pre-releases, including the nightly builds and beta releases. Mozilla's build team wants to make these accessible as parallel-installable binaries, released through a Fedora-compatible repository. This project involves setting this up.

Subprojects:

• Build configuration for the RPM files.
• Repository configuration RPMs.
• Getting SELinux to work with the nightlies.

-> Bug 600317
Initial contacts: ctyler, armenzg

Mozilla Projects

hgtools

What if the Mozilla builders were better at managing all the different working directories (from Mercurial checkouts) that we need at any give time? If you look at this conversation from IRC you can see the benefits of this and a patch that has the initial work. Initial contacts: Armenzg

ScriptFactory

Imagine that we did not have to touch the Mozilla buildbot factories but instead we maintained a bunch of script for all the different jobs they run?

It would be good if we could create scripts that told a machine how to generate an optimized build, a debug build, unit tests, talos runs, locale repackages. If you look in the tools/scripts repo you can see that we have a simple shell file to do this for the fuzzing automation. The buildbot factory that calls it is called ScriptFactory and it is very simple.

Initial contacts: Armenzg

End-to-end project

How can we build faster and provide tests results faster to our developers? That is what we are trying to figure out and we will be adding bugs to this tracking bug to optimize our infrastructure.

Initial contacts: Armenzg

I don't like waiting - give me a CPU!

We have a hundred jobs running per hour and we sometimes have jobs that have to wait for something before getting started. If we optimized the load we could use the build resources more effectively. I will be adding bugs to this tracking bug to reduce our load on our pools and therefore reduce our waiting times.

Initial contacts: Armenzg