EngineeringProductivity/Projects/Conduit: Difference between revisions

EngineeringProductivity/Projects/Conduit (view source)

Revision as of 16:57, 4 April 2017

1,501 bytes added , 4 April 2017

→‎Problems Conduit Solves: tracking, analysis

Mcote

Confirmed users

1,927

edits

@@ Line 44: / Line 44: @@
 ** this is particularly important in our workflow because some developers use different hg author names/emails from what they use in Bugzilla
 * a stack of commits can be landed at once
+Furthermore, an advanced Autoland service can combine multiple sources, such as servo code from GitHub.
+== Tracking and Visualization ==
+In the Firefox development and release process, code changes traditionally follow this process:
+. Developer pushes patch to Bugzilla
+a. Developer may push patch to Try for test results, which may or may not be posted to or linked from the bug
+. After the patch gets an r+, developer commits and pushes to mozilla-inbound
+. Sheriff merges changeset to the mozilla-central branch.
+. A Nightly build is created which contains the changeset.
+. The changeset is merged to the aurora branch.
+. An Aurora build is created which contains the changeset.
+. Repeat steps 5-6 for beta and release.
+At any point, the changeset may also be backed out of a particular branch and later reapplied (in a modified form).
+There is currently no straightforward way to track or see work "move" across the branches and builds.  The combination of a central commit index plus an integrated Autoland service would provide this view and would be of use to developers and release managers.
+== Static Analysis and Other Reports ==
+With a microservice architecture and a commit index, adding a new analysis step, either manually or automatically initiated, becomes straightforward.  Commits can be easily pulled down to a testing server straight from the staging repo and results either posted to the bug or code-review tool, or pulled into the commit index for visualization.
 == Microcommits ==