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 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Thu, Mar 22, 2012 at 3:57 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote: I kinda like the idea of both. We need a wmf-branch (specific hacks for us, ability to trail master when need be), but having tags is super useful too.

Why not just have the branch but make a new tag before any scap? Best of both worlds ;-)

I disagree here. The wmf branches should always be linear, and you should never merge to it without accepting that it may get scapped.

On Fri, Mar 23, 2012 at 1:11 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: Well true, but I still don't see an instance where you'd merge to master but *not* be willing to have it deployed.

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.

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

The plan right now is to use extensions as submodules on the wmf branch. Updating your extension in deployment is just a matter of updating the referenced commit and then running `git submodule update` on fenari.

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.