On Wed, Sep 25, 2013 at 3:01 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkiller@gmail.com wrote:
wmf-foo -> 1.22wmf19 wmf-bar -> 1.22wmf20 wmf-baz -> 1.22wmf21 wmf-foo -> 1.22wmf22 wmf-bar -> 1.22wmf23
This looks like it's exactly the same concept as slot0/slot1/slot2 in Ryan's git-deploy proposal.
The objection that I would have to this is that it makes the cherry-picking workflow less intuitive. You have to know which of wmf-{foo,bar,baz} to cherry-pick to, rather than being able to cherry-pick to wmf23 or whatever. Also, because the wmfN tags can only be created after they're no longer live (because only at that point do we know they'll have stopped changing), you can't actually find the *current* wmfN anywhere, because it won't have been tagged yet.
I agree, I think this would make the deployment process more error-prone.
How about having a "legacy" branch with tags for each wmf deployment that isn't actually on the cluster? So then we only need 3ish branches (legacy, and the current 2 in production), but deployers still work with wmf18, wmf19, etc?
The motivation is to "stop making new branches all the time", but tags and branches are equally cheap. A tag is just a frozen branch that can't advance. If you're trying to "tag" something but it can still change, use a branch. And that's what our deployment branches are, IMO.
Roan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l