MozillaWiki

Community:SummerOfCode15: Difference between revisions

Page Discussion

Community:SummerOfCode15 (view source)

Revision as of 11:08, 16 December 2015

14,141 bytes added ,  16 December 2015
→‎Firefox: Not mentoring the Download Integrity project right now
(Added some example rest APIs)
(→‎Firefox: Not mentoring the Download Integrity project right now)
 
(16 intermediate revisions by 7 users not shown)
Line 31: Line 31:
! Comments
! Comments
|-
|-
| Download Integrity
| Enhance detection of broken downloads in Firefox. Methods may include:<ul><li>[http://www.w3.org/TR/SRI/#the-a-element-1 Subresource Integrity for the <a> element]<li>[[Features/HTTP_Digest_header_verification#Stage_1:_Definition|HTTP Digest header verification]]<li>Network-level indications like bad HTTP framing</ul>The activities include:<ul><li>Implement the front-end in JavaScript to display failed integrity checks<li>Implement and/or use the required back-end features in C++<li>Work with the Mozilla community to discuss and refine the behavior of the feature, including which methods should be implemented first</ul>
| C++, JavaScript
| [https://mozillians.org/en-US/u/paolo/ Paolo]
|
|
|}
== Firefox Developer Tools ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Source Map Library
| This project would implement missing library support for certain of the source map spec, specifically "indexed" source maps, and experimenting with extensions for encoding the original source code's lexical environment in the source map.
| JavaScript, Node.js
| [https://mozillians.org/en-US/u/fitzgen/ fitzgen]
| [https://mozillians.org/en-US/u/fitzgen/ fitzgen]
| Easy for a contributor to ramp up on, because it can be done completely in Node.js without needing to build Firefox.
|}
|}


Line 76: Line 101:
| rkent
| rkent
|
|
|-
| Alternate protocol for mailnews folders
| Thunderbird has long-term plans to implement a variety of mail and mail-like protocols to be managed as mailnews folders. An existing addon (SkinkGlue) exists to provide the glue for this. Implement one other protocol, which might be Fastmail's JMAP, or Calendar events & tasks
| JavaScript
| rkent
| rkent and, depending on protocol brong from Fastmail, or Fallen
| I doubt having 2 twitter implementations in Thunderbird is a valuable investment of time. JMAP seems the most promising protocol idea here; do we know if brong is on board to (co-)mentor this? Even though the code would be primarily written in JS, I suspect having some C++ skills to be able to understand some of mailnews' internals would be very helpful.
|}
|}


Line 89: Line 121:
! Comments
! Comments
|-
|-
| Improve the JavaScript XMPP implementation and implement new features.
| Includes better error handling, implementing multi-user chats (MUCs), test coverage and adding new/missing features. Feature-parity with libpurple's XMPP implementation is one of the prerequisites for replacing it with the JavaScript implementation and is an end-goal of this project. Students are expected to compile a list of bugs or unimplemented features in the JavaScript XMPP code.
| JavaScript, XPCOM, an understanding of XMPP is desired
| Florian Quèze
| aleth, Patrick Cloke [:clokep]
|
|-
| Implement a new protocol plug-in in JavaScript
| Instantbird supports protocol plugins implemented in JavaScript. The student will add support for a new protocol in Instantbird. The student working on new protocols should take every opportunity to improve the code and APIs shared by all JavaScript protocol plugins (IRC, XMPP, Yahoo and Twitter). It is expected that the student research the feasibility of interoperability concerns of the protocol during the application period. Students are expected to implement a protocol they use on a day-to-day basis to dog-food the code.
| JavaScript, XPCOM, maybe js-ctypes, understanding of network protocols
| Patrick Cloke
| Patrick Cloke [:clokep]
| Possible protocols include: Google Hangouts, Facebook, WhatsApp, SIP, Bonjour, OSCAR, TextSecure or Telegram
|-
| File transfer support
| API design, backend implementation, frontend UI for supporting file transfers in Instantbird.
| XPCOM, JavaScript, webrtc, networking protocols
| nhnt11
| Patrick Cloke [:clokep]
|
|}
|}


Line 129: Line 181:
! Comments
! Comments
|-
|-
| Bugzilla Extension Exchange Format
| Write an installer script for Bugzilla extensions
| Perl
| dylan (dylan@mozilla.com)
| dylan
| Spec: http://hardison.net/~dylan/BEEF.html
|}
|}


Line 178: Line 236:
| [[https://mozillians.org/en-US/u/mwargers/ Martijn Wargers]], [[https://mozillians.org/en-US/u/jmaher/ Joel Maher]]
| [[https://mozillians.org/en-US/u/mwargers/ Martijn Wargers]], [[https://mozillians.org/en-US/u/jmaher/ 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.
| 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.
|-
|mozregression GUI
|Using Python, create a graphical user interface for mozregression (http://mozilla.github.io/mozregression) along with an installer and automatic update system to make it easier for less technical contributors to find and report regression ranges in Firefox and Thunderbird.
|Python
|[mailto:wlachance@mozilla.com William Lachance]
|[mailto:wlachance@mozilla.com William Lachance], [mailto:j.parkouss@gmail.com Julien Pagès]
|-
| Convert Mozmill test cases to Marionette
| he Mozmill framework is being replaced by Marionette to support multi-process Firefox.  In the previous Mozmill toolchain we have dozens of libraries and hundreds of tests.  This project will entail assessing those tests for uniqueness (compared to browser-chrome) and porting what tests and libraries make sense to Marionette.  The goal here is to assess all the tests and have at least 75 converted.
| Python, Javascript
| [[https://mozillians.org/en-US/u/jmaher/ Joel Maher]]
| [[https://mozillians.org/en-US/u/jmaher/ Joel Maher]], [[https://mozillians.org/en-US/u/whimboo/ Henrik Skupin]]
| Existing tests live here:
http://hg.mozilla.org/qa/mozmill-tests/file/default
new tests live here:
https://github.com/mozilla/firefox-ui-tests
|}
|}


Line 192: Line 267:
|-
|-
| Define, test, and publish json hyperschemas for all release engineering APIs
| 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/.
| We have several APIs (e.g. buildapi, clobberer, (modern) mapper, mozpool, slavealloc, 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/.
 
At the moment we have many systems that were developed before RelengAPI was created, and therefore not all our services are deployed into RelengAPI.
 
Since we have many systems deployed built on different technologies (RelengAPI and Buildbot are two examples of this) with many of them supporting a REST API, we wanted to define a standard way of describing these web services, that would be sufficiently generic that we could automatically generate documentation, generate client libraries (e.g. in python, node.js, go, java, …) that could interact with the API endpoints.


Example REST apis that we have are:
Example REST apis that we have are:


* Build API: https://wiki.mozilla.org/ReleaseEngineering/Applications/BuildAPI
* Build API: https://wiki.mozilla.org/ReleaseEngineering/Applications/BuildAPI
* Mapper: https://wiki.mozilla.org/ReleaseEngineering/Applications/Mapper
* Clobberer: https://api.pub.build.mozilla.org/docs/usage/clobberer/#endpoints
* Clobberer: https://api.pub.build.mozilla.org/docs/usage/clobberer/#endpoints
* (Modern) Mapper: https://wiki.mozilla.org/ReleaseEngineering/Applications/Mapper
* Mozpool: http://hg.mozilla.org/build/mozpool/file/tip/API.txt
* Slave API: http://mozilla-slaveapi.readthedocs.org/en/latest/api/#slaves-slave-actions-disable
* Slave API: http://mozilla-slaveapi.readthedocs.org/en/latest/api/#slaves-slave-actions-disable


Line 213: Line 285:
* https://brandur.org/elegant-apis (for json hyper schema)
* https://brandur.org/elegant-apis (for json hyper schema)
* http://json-schema.org/
* http://json-schema.org/
|-
| Decouple Mozharness internals by breaking it into standalone modules
| What is Mozharness: It's a configuration-driven script harness that is used for automating > 90% of Mozilla's build and test jobs. It is also used by release engineering services outside of continuous integration.
What needs to decoupled: Mozharness has reached some scaling issues. Jobs that do builds and tests inherit and share exhaustive number of mixins. This leads to a complicated Method Resolution Order and objects with too many attrs that are not even needed.
How can this be done: replace the mixins with standalone classes that act as services. The classes can be instantiated many times and are aware of only their own responsibilities. Once stand alone, you then make them into packages within a mozharness library and installable by pip.
The benefit:
* better scalability
* more pythonic so the entry for contribution is less intimidating
* tools outside of mozharness can avail of subcomponents of mozharness
steps and goals for gsoc:
* part (1) take mixins like log.py, config.py, buildbot.py, python.py, signing.py, and tooltool.py and convert them from mixins to standalone classes
** example of how that's done: {{bug|1063532}}
* part (2) turn the now standalone classes into python packages
| python, solid programming skills, enthusiasm
| [mailto:jlund@mozilla.com Jordan Lund], Armen Zambrano
| [mailto:jlund@mozilla.com Jordan Lund]
| more details:
* https://docs.google.com/a/mozilla.com/document/d/1AQZT9opDkqb0tgZaVAtfAX2_dVWFHNWmz0ImgS5-hPM
* https://etherpad.mozilla.org/mozharness-mixins
* http://hg.mozilla.org/build/mozharness
|}
|}


Line 226: Line 327:
! Comments
! Comments
|-
|-
| rustfmt
| Create a code formatting tool that automatically reformats Rust code to meet conventions.
| Experience with Rust.
| [https://mozillians.org/en-US/u/brson brson]
| [https://mozillians.org/en-US/u/brson brson], [http://www.rustaceans.org/nick29581 nrc]
|
|-
| Rust Code Completion for SublimeText
| This project would develop a plugin for the Sublime Text editor that provides code completion for the Rust programming language, by integrating with the Rust [https://github.com/phildawes/racer Racer] project. This would require interfacing between Python (for the Plugin) and Rust (for Racer).
| Rust, Python
| [https://mozillians.org/en-US/u/pnkfelix pnkfelix]
| [https://mozillians.org/en-US/u/pnkfelix pnkfelix]
|
|-
| Refactoring Rust
| Create a tool for refactoring Rust code.
| Experience with Rust.
| [http://www.rustaceans.org/nick29581 nrc]
| [http://www.rustaceans.org/nick29581 nrc]
|
|-
| Tools and macros
| Develop tools and/or APIs for comprehension and manipulation of macros. For example, extend DXR to work with macros or demonstrate a proof of concept refactoring or formatting tool that works with macros.
| Experience with Rust, particularly macros.
| [http://www.rustaceans.org/nick29581 nrc]
| [http://www.rustaceans.org/nick29581 nrc]
|
|}
|}


Line 250: Line 378:
| [https://mozillians.org/en-US/u/jdm/ jdm]
| [https://mozillians.org/en-US/u/jdm/ jdm]
| [https://mozillians.org/en-US/u/seanmonstar/ seanmonstar] and [https://github.com/reem/ reem]
| [https://mozillians.org/en-US/u/seanmonstar/ seanmonstar] and [https://github.com/reem/ reem]
|-
| Server-Sent Events
| Servo lacks an implementation of the [https://developer.mozilla.org/en-US/docs/Web/API/EventSource EventSource Web API]. The goal of this project is to implement that API, following the [https://html.spec.whatwg.org/multipage/comms.html#server-sent-events specification] as closely as possible and enabling the [https://github.com/w3c/web-platform-tests/tree/master/eventsource tests] for this feature that already exist.
| Prior experience with [http://www.rust-lang.org/ Rust] valuable. Comfortable reading and writing JavaScript for the web.
| [https://mozillians.org/en-US/u/jdm/ jdm]
| [https://mozillians.org/en-US/u/jdm/ jdm]
|
|-
| Improve form support
| Servo currently has rather basic form support, with simple widgets. We lack support for many form controls and functionality like file uploads and form validation. We'd like to add support for most form behavior, based on the [https://html.spec.whatwg.org/multipage/forms.html specification].
| Familiarity with web HTML/Javascript. Prior experience with [http://www.rust-lang.org/ Rust] and/or reading web specifications valuable.
| [https://mozillians.org/en-US/u/Manishearth Manishearth]
| [https://mozillians.org/en-US/u/Manishearth Manishearth] (or [https://mozillians.org/en-US/u/jdm/ jdm])
|
|}
|}


Line 278: Line 420:
|}
|}


== Open(Art) ==
== OpenArt ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 289: Line 431:
! Comments  
! Comments  
|-
|-
| [https://github.com/noflo/noflo-ui NoFlo-UI]
| Implement an UI widget on noflo-ui. It could be a timeline (see [https://github.com/noflo/noflo-ui/issues/151 this issue]), plugins for IIP editing or packet display for particular data types. Considering the timeline widget, an initial prototype could be a component library (see [https://github.com/noflo/noflo-tween/blob/master/components/Timeline.coffee noflo-tween]). Proposals should include sketches and an implemented prototype (pull requested to noflo-ui).
| javascript, coffeescript, ux
| [[User:Forresto|Forresto]]
| [[User:Forresto|Forresto]]
| [http://noflojs.org NoFlo] is a JS dataflow implementation and has runtimes for browser, image processing ([https://github.com/jonnor/imgflo imgflo]), microcontrollers ([https://github.com/jonnor/microflo microflo]), SuperCollider ([https://github.com/jonnor/sndflo sndflo]) and other targets. [https://app.flowhub.io Flowhub] is the browser-based IDE for the creation of NoFlo graphs.
|-
| [https://github.com/tweenjs/tween.js Tween.JS]
| Port Tween.js to ES6 and make it a modern citizen of the JS world
| javascript, web animations, graphics
| [[User:Sole|Sole]]
| [[User:Sole|Sole]]
| Tween.JS is a small engine for declaring and running interpolations between values. It's used in interactive experiences, games and all sorts of projects.
|-
| [https://github.com/sole/Animated_GIF Animated_GIF]
| Refactor and build a version 2, splitting the library into independent reusable modules. Also work on compatibility with Firefox OS.
| javascript, web animations, graphics, web workers, pixel handling, canvas
| [[User:Sole|Sole]]
| [[User:Sole|Sole]]
| Animated_GIF is a library for generating Animated GIFs on the browser. It's used in demo apps in mozilla, some properties at webmaker, the wildly successful chat at meatspac.es and who knows where else.
|-
| Create image filters using [http://noflojs.org NoFlo]
| It's possible to start prototyping image filters using [https://app.flowhub.io Flowhub] (use [https://www.filterforge.com/ Filter Forge]'s filters as inspiration and our porting of [https://github.com/jonnor/imgflo/wiki/Recreating-Instagram-filters some Instagram filters]) and components libraries like [http://github.com/noflo/noflo-image noflo-image] and [http://github.com/noflo/noflo-canvas noflo-canvas], then port the filters to imgflo. Another option is to create filters directly on imgflo using GEGL. Proposals should include a running NoFlo graph for a non-trivial image filter, together with sketches and original/processed images. Imgflo+GEGL filters are preferred. Pull requests to noflo-image and imgflo are a plus.
| javascript, coffeescript, noflo, cpp, computer vision basics
| [[User:Vilsonvieira|Vilson Vieira]]
| [[User:Vilsonvieira|Vilson Vieira]]
| [http://noflojs.org NoFlo] is a JS dataflow implementation and has runtimes for browser, image processing ([https://github.com/jonnor/imgflo imgflo]), microcontrollers ([https://github.com/jonnor/microflo microflo]), SuperCollider ([https://github.com/jonnor/sndflo sndflo]) and other targets. [https://app.flowhub.io Flowhub] is the browser-based IDE for the creation of NoFlo graphs. [http://gegl.org GEGL] is a graph-based image processing framework used by imgflo (it's also possible to use noflo-canvas instead of GEGL, but GEGL is preferred due to performance reasons).
|}
== Webmaker ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Automated front-end testing
| Help build automated front-end tests for our Cordova App and investigate different cross-platform continuous integration systems (e.g. sauce labs), with a specific emphasis on Android and Firefox OS.
| javascript, nodejs
| [[User:k88hudson|k88hudson]]
| [[User:k88hudson|k88hudson]]
|
|-
| Community moderation for webmaker.app
| Help build/improve admin interface, integrate with our services architecture to help choose featured content and support community moderation
| javascript, nodejs, css, html
| [[User:k88hudson|k88hudson]]
| [[User:k88hudson|k88hudson]]
|
|}
|}


Line 301: Line 496:
! Mentor(s)  
! Mentor(s)  
! Comments
! Comments
|-
| [http://www.mozillascience.org/projects/codemeta Code as a Research Object]
| Using the proposed [https://github.com/mbjones/codemeta crosswalk schema] between existing software metadata, create a service (can be a simple website) that will allow users to search and filter software across existing data archives and repositories (Zenodo, figshare, GitHub). Comparing the existing schemas for code storage to help create a metadata standard that allows for discoverability, reuse and citation.
| json, [http://zenodo.org/dev zenodo api], [http://api.figshare.com/docs/intro.html figshare api], [https://developer.github.com/ github api]
| [[User:Abby|Abby]]
| [[User:Abby|Abby]]
| "Code as a Research Object" is exploring integrating software into the scholarly workflow. Collaboration with GitHub, figshare and Zenodo.
Background reading: http://www.mozillascience.org/code-as-as-research-object-new-phase/
http://www.mozillascience.org/code-as-a-research-object-metadata-for-software-discovery/
http://www.mozillascience.org/code-as-a-research-object-updates-prototypes-next-steps/
|-
|-
|}
|}
P.A.
Confirmed users
183

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1056302...1109466"