Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
Community:SummerOfCode13: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
* It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that probably improves your chances a little. However, more than 3 seems like spam. | * It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that probably improves your chances a little. However, more than 3 seems like spam. | ||
Questions of any sort? Send mail to [mailto:gerv@mozilla.org | Questions of any sort? Send mail to [mailto:gerv@mozilla.org,florian@queze.net Gerv and Florian]. We will try and respond as soon as possible and get your questions directed to the right person. Please allow at least 48 hours for a reply. If you want to contact a mentor and contact details are not here, ask people in the #developers channel on IRC: irc://irc.mozilla.org/#developers. | ||
== Mozilla Platform (Gecko) == | == Mozilla Platform (Gecko) == | ||
| Line 141: | Line 141: | ||
! Mentor(s) | ! Mentor(s) | ||
! Comments | ! Comments | ||
|- | |||
| Thunderbird Tests | |||
| Thunderbird's test coverage is not as complete as it could be. This task is to write tests, where they are missing, for Thunderbird features. We also have some contributors writing patches that were rejected because the contributor was not also able to produce a test for the feature (which can be much harder than just producing the feature/fix). So the task would also involve the student picking up and helping with these patches. Example bugs: {{bug|580349}}, {{bug|379831}}, {{bug|253830}}. It would be a great opportunity to get to know several different areas of the Thunderbird codebase. | |||
| Javascript required. Experience with mozmill or xpcshell test infrastructure an advantage. | |||
| aceman | |||
| [mailto:mconley@mozilla.com mconley] | |||
| | |||
|- | |||
| Backend Connectors for 'Ensemble' | |||
| mconley is writing a new address book for Thunderbird. This should be stable enough by the summer so that it is possible to write new connectors to connect to various contact storage backends. We will only be targeting read-only support this summer - writing contacts back will come later. Possible backends include: system address book on any platform, LDAP, CardDAV servers, and Google Contacts. [https://github.com/mikeconley/thunderbird-ensemble/wiki/Contact-Service-Connector-API-Proposal-Draft The connector API is specified here, but may evolve during the project]. Applicants should specify which backend they're interested in implementing, and should be highly proficient in Javascript. C/C++ is a bonus, but not entirely necessary. Previous experience working with their chosen backend is highly desirable. Thorough tests for the new connector will be expected. | |||
| JS, although some C/C++ for native may be necessary | |||
| jcranmer | |||
| [mailto:mconley@mozilla.com mconley] | |||
|- | |||
| 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. | |||
| C++, although some JS may be necessary | |||
| jcranmer | |||
| [mailto:Pidgeot18@verizon.net jcranmer] | |||
| | |||
|} | |} | ||
| Line 221: | Line 241: | ||
| Clint Talbert (IRC: ctalbert) | | Clint Talbert (IRC: ctalbert) | ||
| Clint Talbert (IRC: ctalbert) | | Clint Talbert (IRC: ctalbert) | ||
| | |||
|- | |||
| Improve Usefulness and Ergonomics of Peptest | |||
| [https://wiki.mozilla.org/Community:SummerOfCode13 Peptest] is a test framework that was written to test the responsiveness of Firefox. In it's current state it is more of a proof of concept that still needs to be fleshed out with all the bells and whistles that will make it truly useful to developers. Some tasks include integration with the built-in [https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler profiler], using [https://developer.mozilla.org/en-US/docs/Marionette Marionette] as a back-end to drive tests (will also make it easier to run peptests on mobile platforms), improvements to the API exposed to test authors, multitude of other minor tweaks that help make the Peptest experience as painless as possible. | |||
| Python and javascript | |||
| Andrew Halberstadt (irc: ahal) | |||
| Andrew Halberstadt (irc: ahal) | |||
| | | | ||
|} | |} | ||
| Line 306: | Line 333: | ||
! Mentor(s) | ! Mentor(s) | ||
! Comments | ! Comments | ||
|} | |||
== Rust == | |||
{| class="standard-table" border="1" style="border-collapse: collapse" | |||
|- | |||
! Title | |||
! Details | |||
! Skills Needed | |||
! Reporter | |||
! Mentor(s) | |||
! Comments | |||
|- | |||
| Rust Debug Symbol Generation | |||
| [http://www.rust-lang.org/ Rust] is a new compiled programming language that Mozilla is working on. At the moment, Rust programs are tricky to debug when they don't work because they lack debugging symbols. This work has been started, but for many core Rust features the current debugging support is little to none. The goal of this project would be to support building the self-hosted (i.e. written in Rust) compiler with full debugging symbols enabled, and fill out the suite of automated gdb tests to ensure that the debugging support does not regress in the future. The project will require making use of [http://llvm.org/ LLVM]'s [http://llvm.org/docs/SourceLevelDebugging.html source-level debugging features] and building on the debugging support that [https://github.com/mozilla/rust/blob/master/src/librustc/middle/trans/debuginfo.rs already exists in the compiler]. | |||
| Rust, LLVM experience beneficial | |||
| Josh Matthews (jdm) | |||
| Josh Matthews (jdm) | |||
| Practical experience with Rust is rare. Therefore, any student interested in this project should take some time to become familiar with Rust so that the actual project time is spent on practical work instead of learning the language. | |||
|} | |} | ||
| Line 343: | Line 389: | ||
|[mailto:greg@mozillafoundation.org gvwilson] | |[mailto:greg@mozillafoundation.org gvwilson] | ||
| | | | ||
|- | |||
| Meemoo Media Server | |||
| Meemoo is a framework for connecting open-source modules, powered by any web technology - "hackable web apps". This task is to design a method to record audio and video locally, using WebRTC streaming to a local Node.js server. Saving images could also be a good goal. It should be easy to save media and then bring it back into the [http://www.meemoo.org Meemoo] app. | |||
| JavaScript, WebRTC, Node.js | |||
| Forrest Oliphant | |||
| [mailto:forrest@sembiki.com Forrest Oliphant] | |||
| | |||
|} | |} | ||
| Line 432: | Line 485: | ||
! Mentor(s) | ! Mentor(s) | ||
! Comments | ! Comments | ||
|- | |||
| Project Janus | |||
| Build a Firefox addon that emulates dynamic profile switching, like Chrome supports signing in as multiple profiles. The actual profile-switching code is out of scope of a GSoC project, but writing a visual stub that users can interact with would give us valuable information as to what kind of support (real multiple profiles, Guest Mode, Private Mode) are most useful to people. The addon would need to collect metrics, e.g. how often to people switch profiles, how many profiles does an average user need, how many sites to people access across multiple profiles. Building a Chrome extension to collect the same metrics would also be very useful. | |||
| Javascript, Addon SDK | |||
| Monica Chew (mmc) | |||
| Monica Chew (mmc), Tanvi Vyas (tanvi) | |||
| This is primarily a quantitative user experience project. | |||
|} | |} | ||