SBR600 Potential Projects
- 1 Introduction
- 2 Fedora-ARM Projects
- 3 Fedora Projects
- 4 Fedora-Mozilla Projects
- 5 Mozilla Projects
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.
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).
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.
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.
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.
Fedora-ARM Dogfood - Koji Hub
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.
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.
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.
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.
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 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
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.
- Build configuration for the RPM files.
- Repository configuration RPMs.
- Getting SELinux to work with the nightlies.
What if the Mozilla builders was better at managing all the different working directories (from Mercurial checkouts) 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
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
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