Confirm
161
edits
Changes
→Release Engineering: Move RelEng project from brainstorming page
* https://brandur.org/elegant-apis (for json hyper schema)
* 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
|}
