[[Category:SBR600]]{{Chris Tyler Draft}}[[Category:Winter 2012 SBR600]]
= 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 [[Winter 2011 Fall 2013 SBR600 Participants|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 [[User:Chris Tyler|Chris Tyler]]).
== Notes ==
Each project listing contains a general description, plus this information:
* Maximum number of students - Do not exceed this number without approval from [[User:Chris Tyler|your professor]].
* Skills required - This is a rough list of some of the skills required for this project. This list may be incomplete or inaccurate, but it will give you a starting point in evaluating whether this project is a good fit for you. It is not assumed that you will have all of these skills at the outset of the project -- some of them will be picked up as you do the project.
* Resources - An initial list of computer and information resources to get started on the project.
* Expected result - A rough indication of what is expected at the conclusion of the project.
You will have an opportunity to investigate, expand upon, and fine-tune this information as you prepare your initial project plan. For example, you may come up with a more detail list of expected results (deliverables), resources, and contacts during your planning.
{{Admon/important|Individual Deliverables|Note that when multiple people are working on the same project, they will have independent deliverables -- it's not really group work, but rather separate, closely related projects.}}
== [[Sample 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)''' section on the project page. Otherwise, you can become a contributor later.
= Raspberry Pi FedoraRemix Projects = == Update the raspberrypi-config package == The raspberrypi-config package contains the default configuration files for Pidora. These files need to be updated to reflect new options available in the Raspberry Pi firmware, as well as options that are not commonly used and may conflict with common use-cases - for example, the current configuration files cause kernel start-up messages to be reported on the serial port. This is rarely used, any may cause conflicts with other devices connected to that port (e.g., LCD displays). Skills required: packaging Maximum number of participants: 1 Expected result: An updated, working raspberrypi-config package == Kernel Configuration Files == The build process for the kernel uses a configuration file to control which kernel capabilities are built into the kernel itself, which are built as loadable modules, and which are not built. The Pidora kernel configuration file is a combination of the RaspberryPi default configuration file and the Fedora configuration file. This project involves reviewing the Pidora kernel configuration to optimize it for the widest possible range of use-cases while ensuring a fairly small kernel image size. Skills required: kernel configuration/building, packaging Maximum number of participants: 1 Expected result: An improved kernel configuration in the raspberrypi-kernel package == Profile and Improve RPM and YUM performance on the Pi == RPM/YUM appear to perform slowly on the Pi -- which is appropriate, since the Pi has a slower processor and storage system than most modern PCs -- but the performance can probably be improved. This project involves profileing the RPM/YUM operations to determine which parts of the processing are slowest, and then examining how those parts work to see if any improvements in speed are possible. Skills required: profiling, programming, packaging Maximum number of participants: 1 Expected result: Either a report proving that RPM/YUM are as fast as can be expected on the Pi, or changes to affected packages to improve performance == Internationalization Support in Firstboot for Pidora 19 == This project involves taking the Pidora 19 Firstboot package and internationalizing it (making it possible to use multiple language files with Firstboot). Note that Pidora 19 is expected to use a Fedora 18-ARM Projects style Firstboot system (as was used in Pidora 18) rather than the firstboot system used in Fedora 19 and higher. Skills required: python, i11n using gettext, packaging Maximum number of participants: 1 Expected result: A version of firstboot and the firstboot modules that are fully internationalized == New Firstboot for Pidora 20 == Firstboot on the Pi varies a bit from firstboot on PCs, because the software isn't installed onto storage in the same way as PCs. This project involves updating the Fedora 20 firstboot package to work with Pidora 20. Skills required: python programming, packaging, testing Maximum number of participants: 1 Expected result: A version of the Fedora 19 or Fedora 20 firstboot that works on the Pi and has full support for the Pidora options (such as rootfs resizing) == Compiler Flags on Pidora ==
== System Administration Tools We're not sure if the compiler flags being used for Pidora are optimal. This project involves building a number of packages with different combinations of compiler flags, observing the results (in terms of binary size and performance) and recommending the ARM Build Farm ==optimal set of flags.
The [[Fedora ARM Koji Buildsystem]] or "farm" consists of 23 ARM builder systems which will grow to 38 by the end of this semester. As it growsSkills required: building, the need for efficient system management tools increases. The previous semesters' students started the work of setting up [http://www.nagios.org/ nagios] (monitoring) and [[https://fedorahosted.org/func/ func]] (group control) tools.benchmarking
This project involves configuring these tools to work with all Maximum number of the systems in the ARM build farm, as well as setting up and configuring the [httpparticipants://www.puppetlabs.com/ puppet] (configuration management) tool.1
* Maximum number of students: 2* Skills required: Linux system administration, problem solving, documentation writing* Resources: wiki notes from previous semesters (e.g., [[How to Setup and configure Nagios]]), [[Fedora ARM Koji Buildsystem]], [[CDOT Development Systems]]* Expected result: nagios, func, and puppet working across Modified RPM macros that include the entire ARM build farm; documentation on how to use these tools on the farm and how to add additional devices* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]optimal flags for Pidora
== Koji Hub on ARM Avahi Configuration for Pidora ==
The [[Fedora ARM Koji Buildsystem]] system uses [[CDOT_Development_Systems#Machine_names.2C_IPsAvahi (zeroconf) enables discovery of computers without DNS or IP numbers.2C_and_Status|HongKong]], an x86_64 system, as This project involves configuring Avahi for use on the [[:fedora:Koji|Koji]] hubPi, along with so that other computers can connect to it by name without DNS support. This configuration must then be packaged in such a group of [[Fedora ARM Secondary Architecture/ARM hardware|ARM builders]]way that it can be included in the Pidora composes without causing conflicts.
IdeallySkills required: testing, 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 [http://www.globalscaletechnologies.com/t-openrdcdetails.aspx OpenRD-Client] system as Koji hub and determining if this is a viable configuration.packaging
* Maximum number of studentsparticipants: 1* Skills required: Linux system administration, problem solving, documentation writing* Resources: wiki notes from previous 2 semesters, access to the OpenRD and a GuruPlug or BeagleBoard* Expected result: koji-hub running on the OpenRD; a recommendation on whether the OpenRD is suitable for use as a hub for the Fedora-ARM project* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
== Device Support and TestingExpected results: PandaBoard ==A configuration package that, when installed, will correctly set up Avahi for local discovery on the Pi
Various ARM devices need different driver sets and/or kernels. This project will test == Upstream the Fedora-ARM system on the [http://pandaboard.org/ PandaBoard], creating a kernel that works well with it, and figuring out how to use as many of the built-in peripherals as possible.Pidora RPM Changes ==
* Maximum number of students: 1* Skills required: Linux There are some small changes to the RPM system administration, kernel building, research, documentation writing* Resources: a [http://pandaboardthat have been done for Pidora.org/ PandaBoard], notes from other [http://wwwThese changes need to be included in the upstream version of RPM.omappedia.com/wiki/PandaBoard PanadaBoard support projects],* Expected result: a kernel (or kernels) for use This project involves working with upstream to ensure that these changes are in the PanadaBoard correct format and the Fedora 12 or Fedora 13 root filesystems; user documentation on how to set up the PandaBoard with Fedora; wiki notes on setting up other ARM devices* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paulincluded in subsequent releases of RPM.W|PaulW]]
== Add PandaBoards to the FedoraSkills required: interpersonal skills -ARM Build System ==negotiation, patch creation, packaging
We have 15 [httpMaximum number of participants://pandaboard.org/ PandaBoards] on order for the [[Fedora ARM Koji Buildsystem|Fedora-ARM build farm]]. These machines need to be configured and added into the farm, and then optimized to build packages as quickly as possible.1
* Maximum number of students: 2* Skills required: system administration, network administration, troubleshooting, benchmarking* Resources: PandaBoard systems* Expected result: a filesystem image and documented standard operating procedure for adding PanadaBoards to the build farm; new PandaBoards actively building* Initial contacts: [[User:Chris Tyler|ctyler]], [[Userresults:Paul.W|PaulW]]Pidora RPM changes will be upstreamed
== iSCSI/AoE Support Wayland ==
[http://enFedora 20 includes support for the Wayland display system.wikipedia.org/wiki/ISCSI iSCSI] (SCSI over TCP/IP) and [http://en.wikipedia.org/wiki/ATA_over_Ethernet AoE] (ATA-over-ethernet) are different SAN protocols that can be used The RaspberryPi foundation has been working on a standard ethernet networkWayland implementation for the Pi.[[Fedora ARM Secondary Architecture/iSCSI|iSCSI did not This project involves getting the two to work reliably in Fedora 12 on ARM systems]], but will be needed by future ARM server systems. AoE has not been well-tested on ARM systemstogether.
Goals of this projectSkills required:(1) iSCSI and AoE need to be tested for stability and performance. (2) The ARM builderssystem administration, which currently use loopback-mounted filessystems on top of NFSdebugging, should be reconfigured to use iSCSI or AoE (whichever is the optimal solution) providing it is faster than the current solution.possibly some programming, packaging
* Maximium Maximum number of studentsparticipants: 2* Skills required: Linux system administration, debugging and troubleshooting, kernel building, benchmarking, documentation writing* Resources: an ARM system, CDOT PC systems* Expected result: iSCSI on ARM fixed and tested, and changes pushed upstream; AoE tested on ARM; report comparing iSCSI and AoE performance on ARM; ARM buildsystem configured to use a high-performing iSCSI or AoE storage solution in place of the existing NFS system* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
== CreateRepo Performance Improvements ==Expected results: The Wayland snapshot in Fedora 20 will be usable on the Pi (Ideal: fully packaged; Acceptable: Instructions on how to set it up)
The [[Fedora ARM Koji Buildsystem|Fedora-ARM build farm]] consists of the koji-hub/koji-web system (on [[CDOT_Development_Systems#Machine_names.2C_IPs.2C_and_Status|HongKong]], an x86_64 machine) == Automate Pidora Kernel and a group of ARM builders. HongKong also handles the [[http://createrepo.baseurl.org/ CreateRepo]] tasks, which heavily load that machine. It might make sense to move those tasks to another machine, but doing so makes the CreateRepo jobs take a lot longer (15 minutes on HongKong vs. 55 minutes on another x86_64 server). This is presumably due to the overhead of sharing files between HongKong and the other server over NFS on the 100 Mbps Seneca network.Firmware Building ==
This project involves figuring out how The Raspberry Pi Foundation maintains a kernel fork that is updated frequently. We would like to run the CreateRepo jobs more quickly. Possible solutions include package kernel and firmware changes on a 1 Gbps LANdaily basis, and have these available in a redistribution of the file storage or a change to testing repository so that anyone can use them. Periodically, we will select a different file storage technology, or optimizing kernel-firmware combination from this testing repository and make it available as the CreateRepo tasks on HongKong for best speedmain Pidora kernel.
* Maximum number of students: 1* Skills required: system administration, benchmarking* Resources: CDOT server systems scripting (HongKong, Ireland, Scottlandpython and/or bash)* Expected result: significant reduction in CreateRepo times, especially when multiple CreateRepo tasks are running* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]packaging
== RPM-based Kernels for Fedora ARM ==Maximum number of participants: 1
On PC architecture systems (x86_64 and i386), Fedora manages Expected results: Raspberry Pi kernel and firmware updates kernels as RPM packages, which modify [http://www.gnu.org/software/grub/grub-legacy.en.html grub] boot parameters and the initial ram disk will be included in a package in a testing repository through an automated ([http://en.wikipedia.org/wiki/Initrd initrd], configured by [[:fedora:Dracut dracut]]cron'd).process
On Fedora== Change raspberrypi-ARM systems, the kernel is not managed via RPMs, grub is not used, and the initrd system is rarely used.vc Package to Build from Source ==
This project involves understanding how Originally, the VideoCore IV GPU on the PC (i386/x86_64) kernel/boot/initrd system worksPi was used with proprietary libraries which were only available in compiled form, determining which pieces can be reused on Fedoraso the raspberrypi-ARM vc package was originally set up to package prebuilt binaries and which pieces need to be adapted or replacednot build from source. The source code for these libraries is now available, and implementing RPMthe raspberrypi-based kernel management for ARMvc package should be changed to build from source (this will help with SELinux compatibility).
* Maximum number of students: 3* Skills required: Linux system administration, script writing, RPM packaging, kernel building, initrd debugging* Resources: an ARM system* Expected result: RPM-based Kernels work on Fedora-ARM, with changes committed upstream; documentation about the differences between kernel management on ARM and on PCs* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]
== Fedora-ARM Communication ==Maximum number of participants: 1
We're not doing a great job of communicating how the Fedora-ARM project is doing. The [httpExpected result://arm.koji.fedoraproject.org/status status page] is very bare-bones and doesn't convey a lot A new version of information, the Fedoraraspberrypi-ARM wiki pages need to be made more useful to prospective usersvc package that build from source, and we need an effective communication strategy is compatible with the rest of the Fedora community. This project involves writing some web scripts to create a easy-to-use, informative status page (showing, for example, the current state and progress of the ARM builds), creating user documentation on the Fedora wikiPidora package, and fostering effective communication within the Fedora-ARM project and the larger Fedora community.can be easily updated/maintained
* Maximum number of students: 2* Skills required: Apache administration, script-writing, effective written communication skills* Resources: the web server on HongKong, various data sources within the Fedora-ARM build system, Fedora project communication tools, access to ARM systems* Expected result: a useful (easy-to-use, informative) and automatically-updated Fedora-ARM status page; improved user documentation on the Fedora wiki (e.g., how to set up Fedora-ARM on common devices); better communication on the arm@lists.fedoraproject.org mailing list and the #fedora-arm IRC channel* Initial contacts: [[User:Chris Tyler|ctyler]], [[User:Paul.W|PaulW]]== Write an Updated Boot Screen ==
== Automatic ExclusiveArch Addition/Removal ==Pidora includes an OpenGL-powered boot screen, which uses the Raspberry Pi Fedora Remix logo. The current code does not use OpenGL very effectively.
RPM packages may be specified as being suitable only for particular architectures through the use of ExclusiveArch and ExcludeArch lines in the spec file. If a base This package, such as a language (interpreter or compiler) or a library does not build on a particular architecture, then dozens or hundreds of other packages cannot be built. These packages should all be marked as ExcludeArch in the upstream git package repository. Later, if that base package is updated to work on that arch, use OpenGL better and to use the ExcludeArch lines will need to be removedPidora logo.
This project involves writing a script that will mass-add or mass-remove ExcludeArch tags (orSkills required: C programming, if those tags existOpenGL programming, add or remove a particular architecture), pushing the changes to the upstream git repo.packaging
* Maximum number of studentsparticipants: 1* Skills required: scripting (Python and/or bash), packaging* Expected result: a script that will do mass adds/removals of ExcludeArch tags given a list of packages* Resources: fedpkg source, Fedora package repo* Initial contacts: [[User:Paul.W|PaulW]], [[User:Chris Tyler|ctyler]]
== FedoraExpected result: A visually appealing boot screen, packaged as a drop-ARM Package Building and Troubleshooting ==in replacement for the current boot screen
The [[Fedora ARM Secondary Architecture|Fedora== Update rootfs-ARM]] project is building Fedora 13/14/15 for the ARM architecture. As this proceeds, various problems arise. For example:* Some packages fail to build for ARM. They can be fixed up to build successfully on ARM, or if that's not possible, marked as unsuitable for ARM (ExlcudeArch).* If a group of packages is built to work with a specific version of a library, and a newer version of that library replaces the older version, then the packages that rely on that library can break. This can often be remedied simply by rebuilding the broken package; in other cases, patches are required.resize ==
Note The rootfs-resize package resizes the Pidora rootfs after installation. It works with primary partitions, and it works with the NOOBS system, but it doesn't work with a NOOBS-style layout outside of NOOBS (i.e., where the rootfs is placed in an extended partition). This project involves extending rootfs-resize so that one package build issue will often block many other packagesit can resize extended and logical partitions as well as primary partitions.
This project involves working with other members of the Fedora ARM build team to resolve package build problems and get F13Skills required: Python scripting/F14/F15 released for ARM as soon as possible.programming, system administration, packaging
* Maximum number of studentsparticipants: 4* Skills required: packaging, troubleshooting* Expected result: problems with the Fedora-ARM builds are cleared as quickly as possible; F14-ARM released by the end of the semester* Resources: Fedora-ARM Koji build system, arm@lists.fedoraproject.org mailing list* Initial contacts: [[User:Paul.W|PaulW]], [[User:Chris Tyler|ctyler]]1
= Fedora Projects =Expected result: An updated rootfs-resize package
== Package the Weave Server Packaging Pi-compatible Software ==
Mozilla Sync is There are a technology for synchronizing personal data (bookmarksnumber of Pi-specific software packages that could/should be included in Pidora. Select one, passwords, form valuespackage it, and cookiesget it into Fedora (preferred) across multiple machines. It uses a server known as [https://wiki.mozilla.org/Labs/Weave/Sync/1.0/Setup Weave]or directly into Pidora.
This project involves {{Admon/tip|Finding Your Own Package|You can find any Pi-specific software and propose packaging Weave it for Fedora and getting your project. Note that it through the packagemust be (a) broadly-useful Pi-approval process. specific software, or (Why b) a substantial software package that would be generally useful in Fedora and specifically on the Weave server? So that people can run Pi, in order to be approved as a private version, either for enhanced security or for testing)project.}}
Some possible packages ideas to get you started:* Maximum number of students: 1Adafruit WebIDE* Skills required: Apache administration, packagingAdafruit libraries/tools/etc (select a specific piece of software)* Resources: CDOT systemsOMXplayer* Expected result: Vidcore library compatibility package (symlink farm in /opt/vc so that source code expecting to find the Weave server VC libraries there will be available in the main Fedora repositories (yum install weavework successfully)* Initial contacts: mhoyeQuick2wire python library
== Package Hadoop ==See the [http://trac.proximity.on.ca/projects/rpfr/report/1 Pidora Bug Tracker] for ideas for other packages that people want included in Pidora.
[httpSkills required://hadoop.apache.org/ Apache Hadoop] is a set of tools used for large-scale distributed computing. It would be great to get this packaged for Fedora.packaging
* Maximum number of studentsparticipants: 3* Skills required: packaging, system administration; familiarity with Java programming/packaging* Resources: CDOT systems* Expected result: the three Apache Hadoop subprojects 1 per package (Hadoop Common, HDFS, and MapReduce) will be available in identify the main Fedora repositories (yum install hadoop-common hdfs mapreducepackage!)* Initial contacts: [[User:Chris Tyler|ctyler]]
== Package the WIX Toolchain ==Expected result: A working, Pidora-compatible package that has gone through package review
WIX is an open-source packaging system for Microsoft Windows software. It is used to prepare software packages that can be installed on a Windows machine. However, == Clean Up the WIX tools themselves can run on Linux.Pidora Kickstart File ==
This project involves packaging WIX The Pidora images are composed using a kickstart-based process. The kickstart file could be cleaned up for Fedora better readability and getting it through the smallest-functional package-approval processselection.
* Maximum number of students: 1* Skills required: packaging* Resources: CDOT systems* Expected result: the WIX software will be available in the main Fedora repositories Recent (yum install wixbut not necessarily latest)* Initial contactskickstart: http: mhoye, sdowne<!//scotland.proximity.on.ca/raspberrypi/test-releases/rpfr18v6/latest/pidora-== fedpkg Test Suite ==18.ks
''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 suiteSkills required: packaging, so that as new features are added, regressions can be detected.composing
* Maximum number of studentsparticipants: 2* Initial contacts: [http://jkeating.livejournal.com/ Oxf13]-->1
== Koji Setup Documentation ==Expeccted result: A clean kickstart file for Pidora 19
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.= Infrastructure Projects =
* Maximum number of students: 2* Skills required: writing, system administration* Resources: CDOT systems, Wiki* Expected result: a complete, well-written guide to setting up a Koji system (from A-Z)* Initial contacts: [[User:Chris Tyler|ctyler]], dgilmore== Bug Tracker for Pidora ==
== AutoQA ==[[:fedora:AutoQA|AutoQA]] is an automated test system Pidora currently uses a Trac instance for Fedorabug tracking. At present However, there are event watchers for koji builds, bodhi updates, repo changes, and nightly installed images; these events trigger is a small number lot of testsspammer activity on that system. Implement an effective spam prevention system on Trac, but more tests are neededor implement an alternative bug tracking system such as Bugzilla. Document the solution for future maintainability.
* Maximum number of students: 3* Skills requiresrequired: Python scripting, scripting, system administration, packaging* Resources: CDOT systems* Expected results: additional tests for AutoQA, accepted/committed into the main AutoQA codebase* Initial contacts: [[:fedora:User:JLaska|JLaska]]documentation
= Fedora-Mozilla Projects =Maximum number of participants: 1
== Repository Setup for Mozilla Nightlies and Betas ==Expected result: A spam-resistant bug tracking system
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 == Create a FedoraFedpkg-compatible repository. Last semester, a group of SBR600 students set most of this up; this project involves extending and improving their work.<!-- Subprojects:* Build configuration Package Repository for the RPM files.* Repository configuration RPMs.* Getting SELinux to work with the nightlies.-->Pidora ==
See [https://bugzillaFedpkg is a tool used to manage Fedora packages using GIT (and http).mozillaWe'd like to be able to use it for Pidora-specific (non-Fedora) packages as well.org/show_bugTo set up Fedpkg, a package database (pkgdb), GIT repository, http repository, and Fedpg configuration will be required.cgi?id=600317 bug 600317]Completion of the various components of this project should result in a usable, RPM-installable Fedpkg configuration for Pidora packages.
* Maximum number of students: 2* Skills required: system administration, scriptingtesting, packaging* Resources: scripts and configuration from the previous semester* Expected result: fully-functioning repository configuration ready for installation on Mozilla's systems; well-written documentation* Initial contacts: [[User:Armenzg|armenzg]], [[User:Chris Tyler|ctyler]]
<!-- = 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=589885#c11 this conversation from IRC] you can see the benefits Maximum number of this and [https://bug506404.bugzilla.mozilla.org/attachment.cgi?id=476270 a patch] that has the initial work.Initial contacts: [[Userparticipants:Armenzg|Armenzg]] -->3
<!-- == MozHarness ==Expected result: A working Fedpkg repository, plus configuration files packaged up in an RPM
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?== Mirrorlist CGI Script ==
It would be good if we could create scripts that told Yum uses a mirrorlist retrieved from a machine how server to determine which mirrors to generate an optimized build, use for downloading packages. This mirrorlist can be generated by a debug buildscript (e.g., unit teststo randomize or to optimize mirror selection), talos runs, locale repackages.If you look in but at the [http://hg.mozilla.org/build/tools/file/tip/scripts tools/scripts] repo you can see that we have present time a simple shell static file is just passed through to do this for the fuzzing automation. The buildbot factory that calls it is called [http://hg.mozilla.org/build/buildbotcustom/file/a70b38b40088/process/factory.py#l7895 ScriptFactory] and it is very simpleyum client.
Initial contactsSkills required: [[User:Armenzg|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 [https://bugzilla.mozilla.org/show_bug.cgi?id=598175 tracking bug] to optimizeour infrastructure.scripting, testing
Initial contactsMaximum number of participants: [[User:Armenzg|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 [http://www.themoviemind.com/wp-content/uploads/2008/08/chuck-norris-2.jpg tracking bug] to reduce our load on our pools and therefore reduce our waiting times.1
Initial contactsExpected result: [[User:Armenzg|Armenzg]]-->An updated mirrorlist script