Hi everyone,
This email is going to briefly describe the old SVN workflow, and then
use that as a baseline to describe what we should do for Git. I
haven't had a chance to coordinate this mail with Chad (or anyone
else), so I'll reserve the right for him to completely contradict me
here. This is meant to provoke a discussion about how we're really
going to use Git, and to establish a plan for taking advantage of the
new workflow to move to much more frequent deployments.
In the old world, we had this:
trunk
├── REL1_17
│ └── 1.17wmf1 (branched from REL1_17)
├── REL1_18
│ └── 1.18wmf1 (branched from REL1_18)
└── REL1_19
└── 1.19wmf1 (branched from REL1_19)
Tarball releases would come out of the respective REL1_xx branches,
and deployments would come out of the 1.xxwmf1 branches. REL1_xx
branches have all extensions, and 1.xxwmf1 branches have only
Wikimedia production code. Each would be a relatively long lived
branch (6-18 months) into which critical fixes and priority features
would be merged from trunk.
Looking ahead to deployments, there's a couple of different ways to go
about this:
One plan would be to have a "wmf" branch that does not trail far
behind the master. The extensions we deploy to the cluster can be
included as submodules for that given branch. The process for
deployment at that point will be "merge from master" or "update
submodule reference" on the wmf branch. Then on fenari, you will git
pull and git submodule update before scapping like you're currently
used to. The downside of this approach is that there's not an obvious
way to have multiple production branches in play (heterogeneous
deploy). Seems solvable (e.g wmf1, wmf2, etc), but that also seems
messy.
Another possible plan would be to have something *somewhat* closer to
what we have today, with new branches off of trunk for each
deployment, and deployments happening as frequently as weekly.
master
├── 1.20wmf01
├── 1.20wmf02
├── 1.20wmf03
...
├── 1.20wmf11
├── 1.20wmf12
├── REL1_20
├── 1.21wmf01
├── 1.21wmf02
├── 1.21wmf03
...
This is how I was envisioning the process working, and just didn't get
a chance to sync up with Chad to find out what the issues of this
approach would be.
Since we don't have an imminent deployment coming from Git, we have a
little time to figure this situation out.
Regardless of the branching strategy, the goal would be to start as
early as April with much more frequent deployments to production. The
deployment plan would look something like this:
* Deploy 1.20wmf01 to test2 real soon now (say, no later than April 16).
* Deploy 1.20wmf01 to
mediawiki.org a couple deploy days after that
("deploy day" meaning Monday through Thursday)
* Let simmer for some short-ish amount of time (TBD)
* Roll out 1.20wmf01 to more wikis, eventually making it to all of them
Given the way APC caches and other caching works, I suspect we can't
get away with having more than two simultaneous versions out on the
production cluster, but we could conceivably have a situation where,
for example, a deploy day or two after rolling out 1.20wmf01 out to
the last of the wikis, we then roll out 1.20wmf02 out to test2.
This topic is partially covered here:
https://www.mediawiki.org/wiki/Git/Workflow#Who_can_review.3F_Gerrit_projec…
...but I imagine we'll probably need to revise that based on this
conversation and perhaps break this out into a separate page.
There's a few of us that plan to meet in a couple of weeks to
formalize something here, but perhaps we can get this all hammered out
on-list prior to that.
Thoughts on this process?
Rob