The Ideal Future
[Refer to the main page for additional context.]
Based on discussions to date, everyone seems to have similar ideas about what “supporting git for releng” means. Later posts will highlight the work needed to ensure the ideal can be achieved, and how to arrive there.
For this post, I intend to limit the viewpoint and scope to that of the developer impact. Release notions (such as “system of record”) and scaling issues won’t be mentioned here. (N.B. Those concerns will be a key part of the path to verifying feasibility, but do not change the goal.)
As a reminder, I’m just talking about repositories that are used to produce products. [1]
The Ideal Future
The Ideal: In the future, each contributor will be as free to choose their DVCS of choice as they currently are to choose a text editor.
Since that’s a pretty general statement, let me limit it a bit with some caveats that I expect will apply.
- This may only be true at a technical level, as various teams might have social conventions or alternate tooling that will limit DVCS choices.
- Initial planning will be for products [1] that are released via the Release Engineering team. [2]
- The current set of supported DVCS would be hg and git. By
supported, I think folks roughly mean:
- an officially supported way get the latest revision of any official branch/repository, without any extra work on the part of the developer.
- an officially supported way to interact with existing Mozilla hosted tools, such as the try server, tbpl, etc.
- an officially supported way to commit from the DVCS, that supports the current commit workflow (and policy).
- There will be support of social coding sites. I think support means providing an officially supported mechanism to keep “current” instances of each official branch in the social coding sites. The goal would be to allow developers to utilize the enhanced services offered by those sites to view, clone, and share work prior to doing an official commit.
Next Steps
- This post will help validate that the above vision has a wider consensus. Please pass this link along and add your comments below.
- Keep an eye on the main page for more material.
| [1] | (1, 2) I’m using “products” to distinquish binaries Mozilla provides to the end users to install on their computers from “services” Mozilla hosts. Product examples include Firefox and Thunderbird. Service examples include Sync and BrowserID. |
| [2] | The rationale for starting with existing products is that is where the majority of our developers work. Additionally, the existing continuous build & test infrastructure will place some constraints on DVCS workflows. Once those constraints are documented, other projects can make informed decisions on their usage. |