On 03/12/2013 01:44 PM, Greg Grossmeier wrote:
One of the things that became apparent is that the Features Teams (eg: E2, E3, Visual Editor) tend to have separate branches that they develop on and only merge to master closer to their deploy windows. There is some variation among them, of course, but the general idea stands.
We should clarify whether we're talking about core, extensions, or both.
To my knowledge, E3 does not have any server-side branches for core. In other words, we have what Gerrit calls topics, but not what Gerrit calls branches. Even for big changes like a major update to core login and account creation (https://gerrit.wikimedia.org/r/#/c/30637/), it's still just a big single Gerrit change on master.
For extensions, for the most part we also use master and topics. However, there was recently a notable exception for v2 (a major change) of https://www.mediawiki.org/wiki/Extension:GettingStarted .
This contrasts with the way the WMF Platform team develops; we predominately commit to master as we develop with any new features set as disabled in a config until it is ready. The Features Teams also use the "disabled in a config until ready" bit, of course.
Right, the loging/creation change (Gerrit link above) is using that kind of gating (as well as a query-string override).
What is the reasoning for the use of this development/deployment distinction on the Feature Teams? Mostly it is testing, from what I could tell. Many teams have the development branch running on a test instance that they, well, test against. Then, as things stabilize they merge to master via Gerrit.
In the case of the GettingStarted extension v2, we used a feature branch because it was a user-facing change that took a few weeks to get ready for deployment. Because it was user-facing, there were interactions, and we wanted to test it, we wanted to do it in one shot.
Matt Flaschen