Confirm
87
edits
Changes
Moved a bunch of project ideas from the brainstorm page to the official idea list
! Comments
|-
| Mailbox-to-maildir converter
| Mailbox and Maildir are two alternative on-disk storage formats for email messages. Thunderbird currently uses Mailbox, but wants to use Maildir. Hence the need for a converter. This is one of the last critical pieces blocking moving away from mbox-style mailboxes. See {{bug|856087}}.
| JavaScript, C++
| jcranmer
| rkent
|
|}
! Comments
|-
| Introducing Calendar Accounts
| Traditionally our calendar extension is organized into a list of calendars, each calendar being implemented by a “provider”, for example local storage or using the CalDAV protocol. The service to manage these calendars maintains a simple list, the entries have no connection to each other.
Some calendar providers would greatly benefit from being able to group calendars into accounts, for example free-busy lookups are usually per-server operations and not per-calendar. It would also open the door for some great new features that have been postponed because they can be implemented cleaner with the notion of accounts.
| XUL, CSS, JavaScript
| [mailto:mozilla@kewis.ch Fallen]
| [mailto:mozilla@kewis.ch Fallen]
| [[Media:Calendar-gsoc2015-calmgr.pdf|Click here for a detailed project description]]
|-
| Resource Booking Improvements
| The Lightning extension has a dialog for inviting attendees to an event, which also shows availability information. Albeit not very obvious, it also allows booking resources and rooms. To improve this experience we would like users to be able to pick rooms and resources in a way that they don't need to remember the room address and quickly see which rooms and resources exist and are available around the proposed time of the event.
| XUL, CSS, JavaScript
| [mailto:mozilla@kewis.ch Fallen]
| [mailto:mozilla@kewis.ch Fallen]
| [[Media:Calendar-gsoc2015-resourcebooking.pdf|Click here for a detailed project description]]
|}
! Comments
|-
| Performance Alerts Release Management Toolchain
| This GSOC project will deliver functionality of detecting alerts as they merge between branches. This is mostly important for regressions, but should also include improvements. We generate thousands of performance alerts every year, and we need a way to look at the high level of what is concerning while having the ability to drill down and understand what small details make up the bigger problems. This depends on us seeing these regression when the code was originally introduced and action being taken to file a bug. In many cases we have preferences that turn features on and off which will have an affect on the alerts that we care about. The target here is a release manager can go to a dashboard, and see the state of the release (most important after uplifting code) and get a list of bugs that are of interest.
This will be integrating a system into TreeHerder to store alerts and allow graphs of the data to be annotated. There will be an API so alert can be generated from other sources and managed by other tools as well.
| Python, AngularJS, SQL, Javascript
| Joel Maher
| Joel Maher, Will LaChance
| The impact here is the ability for developers and release managers to see the performance impact of their changes while helping us track this.
|-
| Retry failures in automation and provide annotations for intermittent failures vs real failures
| Of the thousands of unitests which are run for each platform and each push we find many intermittent failures. This is a pain point for developers when they test their code on try server. Now that we have TreeHerder, it isn't much work to automatically annotate jobs as intermittent or a regression/failure. In mochitest we have --bisect-chunk which will retry the given test and determine if it is an intermittent or a real regression. The goal here is to do this automatically for all jobs on try server. Jobs will still turn orange. With the outcome of this project failures would need to have a different view in the UI.
| Python, Javascript
| Joel Maher
| Joel Maher
| This will build off an existing set of tools while helping us bridge the gap towards a much better review and automated landing of patches system. In the short term, this will aid in developers who see failures and either do multiple pushes, many retriggers, or just ignore them- in summary we will not need to worry as much about wasting resources related to intermittents.
|-
| Unittest sanitizer
| With our thousands of test files, there are hundreds that have dangerous api calls which result in leftover preferences, permissions, and timing issues. A lot of work has been done here, we need to fix tests and expand our work on these resources to all our tests. In addition to cleaning up dangerous test code, we need to understand our tests and how reliable they are. We need to build tools that will allow us to determine how safe and reliable our tests are individually and as part of a suite. Upon completion of this project we should have the majority of tests cleaned up, and a toolchain that can be easily run and generate a report on how stable each test is.
| Python, Javascript
| Joel Maher
| Joel Maher
| The impact this has is helping us cleanup our tests to reduce intermittents and give us tools to write better tests and understand our options for running tests in different configurations.
|}
== Release Engineering ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Define, test, and publish json hyperschemas for all release engineering APIs
| We have several APIs (e.g. clobberer, buildapi, mozpool, modern mapper, slaveapi, ...) but have no central standardised way of defining them, publishing them, documenting them, or sharing them. A cool project would be to use json hyperschema (see e.g. https://brandur.org/elegant-apis) to define all our apis, and have a framework for auto testing them, auto-documenting them, even potentially auto-generating client libraries for them e.g. in python, and auto-publishing the schemas to a central location for reference. Another interesting option might be using http://swagger.io/.
| json, json hyperschema, solid programming skills, enthusiasm, code generation, web interface design
| [mailto:pmoore@mozilla.com Pete Moore]
| [mailto:pmoore@mozilla.com Pete Moore]
| Some good starting points:
* http://spacetelescope.github.io/understanding-json-schema/ (for json schema)
* https://brandur.org/elegant-apis (for json hyper schema)
* http://json-schema.org/
|}
! Comments
|-
| Speculative HTML parsing
| Servo's [https://github.com/servo/html5ever/ HTML parser] currently blocks whenever it needs to execute JS code (eg. when <script> tags are encountered in a page). We want to split the HTML parsing code into two threads, one of which can continue parsing the rest of the HTML source [http://www.dorothybrowser.com/portfolio/parallel-parser/ speculatively] while the other is busy executing JS; once the second is finished, the parser can use the result of the first thread's efforts to improve page load performance.
| Prior [http://www.rust-lang.org/ Rust] experience valuable. Familiarity with HTML.
| [https://mozillians.org/en-US/u/jdm/ jdm]
| [https://mozillians.org/en-US/u/kmcallister/ kmc]
|-
| HTTP/2 implementation in hyper
| [https://github.com/hyperium/hyper/ Hyper], the Rust HTTP library that Servo relies upon, is missing support for exciting new technologies like [https://http2.github.io/ HTTP/2]. This project would design and integrate an HTTP/2 implementation into the client and servo code for hyper.
| Experience writing code that interacts with network protocols. Prior [http://www.rust-lang.org/ Rust] experience valuable.
| [https://mozillians.org/en-US/u/jdm/ jdm]
| [https://mozillians.org/en-US/u/seanmonstar/ seanmonstar] and [https://github.com/reem/ reem]
|}
