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