I kinda like the first model (it feels more organic), but the second has the advantage that you've got a previous branch to revert to quickly if needed. That's a plus for deployment work.
-- brion On Mar 22, 2012 12:44 PM, "Rob Lanphier" <[email protected]> wrote: > 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_project_owners > > ...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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
