Confirmed users
329
edits
Multiple Project Repositories: Difference between revisions
Multiple Project Repositories (view source)
Revision as of 01:43, 21 December 2010
, 21 December 2010no edit summary
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
Note that multiple project repos are not necessarily connected to a faster release cycle, but they could be part of the overall release cycle change plan. | Note that multiple project repos are not necessarily connected to a faster release cycle, but they could be part of the overall release cycle change plan. | ||
= Multiple Project Repositories = | |||
Specifically, this page talks about splitting up development into a set of project repositories, similar to the current tracemonkey repo, where changes from the repositories flow into a global repo (perhaps the current mozilla-central). For most of these, I would expect m-c changes to be merged back into the project repo fairly frequently, but that's up for discussion. | |||
== Main Advantages/Disadvantages == | == Main Advantages/Disadvantages == | ||
* When bustage is committed, fewer people are affected | * When bustage is committed, fewer people are affected | ||
* More experimental changes can be made and the problems shaken out because of the smaller | * More experimental changes can be made and the problems shaken out because of the smaller sandboxes | ||
* Easing of the patch bottleneck when the tree gets busy (you just need to space pushes with respect to others in the same tree, not with everyone who might commit anything anywhere) | * Easing of the patch bottleneck when the tree gets busy (you just need to space pushes with respect to others in the same tree, not with everyone who might commit anything anywhere) | ||
* Commit policy can be more closely matched to the needs of a restricted area (eg churn from small changes is less harmful and so more acceptable => more conducive to refactoring) (Note that I would ''not'' expect review policies to differ between repos) | * Commit policy can be more closely matched to the needs of a restricted area (eg churn from small changes is less harmful and so more acceptable => more conducive to refactoring, fewer change freeze periods to discourage external contributors) (Note that I would ''not'' expect review policies to differ between repos) | ||
* More merges are required, and more "clumps" of changes move around the system | * More merges are required, and more "clumps" of changes move around the system | ||
* Less clarity on where individual changes should go, especially for less active (new | * Less clarity on where individual changes should go, especially for less active (new/occasional) contributors | ||
* More overhead for release engineering, QA | * More overhead and resource contention for release engineering, QA, nightly users | ||
* Better correspondence between repos and IRC channels | * Better correspondence between repos and IRC channels | ||
* Harder to see the latest version of everything | |||
* More uncertainty about when a specific change will land in a given repo or nightly | |||
== Questions == | |||
Should all work go into project repos, and mozilla-central be a dedicated merge destination? Or should m-c live on as the default repo, and we'd just increase the number of project repos that we already have? | |||
Will some project repos only feed into mozilla-central, and never get changes merged back? | |||
Do we need "urgent" sub-repositories like Linux kernel development uses? (Changes made to these repos are expected to go directly into the central repo rather than waiting on the next merge.) | |||
== Issues == | == Issues == | ||