So in the interest of keeping our branches from expanding forever I'm thinking we should stop creating new branches for each deploy cycle.
Instead, I'm thinking we should keep like three wmf branches. Let's call them wmf-foo, wmf-bar and wmf-baz for purposes of this e-mail, we can bikeshed later. We'd basically be having the two active branches we have now, plus the previous branch we deployed. When we start a new cycle, the "old" branch becomes the branch new branch, merging everything from master like we do when making a new branch. In practice this would map out to the following:
wmf-foo -> 1.22wmf19 wmf-bar -> 1.22wmf20 wmf-baz -> 1.22wmf21 wmf-foo -> 1.22wmf22 wmf-bar -> 1.22wmf23
And so on and so forth. When creating the new branch we can tag the old one in the same wmf/1.22wmf29 format so it's there for posterity. We could delete all the old branches and turn them into tags.
On the deployment side this is nice because we can just consistently have 3 branches live on the cluster rather than lingering old ones. Switching would be a matter of checking out and scapping rather than cloning and scapping.
Too confusing? Alternative ideas? I'm open to most anything that will stop us making new branches all the time :)
-Chad
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.
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
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
On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkiller@gmail.com wrote:
So in the interest of keeping our branches from expanding forever I'm thinking we should stop creating new branches for each deploy cycle.
What's actually the problem with expanding branches?
Instead, I'm thinking we should keep like three wmf branches. Let's call them wmf-foo, wmf-bar and wmf-baz for purposes of this e-mail, we can bikeshed later. We'd basically be having the two active branches we have now, plus the previous branch we deployed. When we start a new cycle, the "old" branch becomes the branch new branch, merging everything from master like we do when making a new branch.
It seems to me that reusing branch names could get real confusing...
And so on and so forth. When creating the new branch we can tag the old one
in the same wmf/1.22wmf29 format so it's there for posterity. We could delete all the old branches and turn them into tags.
We could also do exactly that when retiring branches from production, without changing the naming schema. Transfer the branch tip to a tag, delete the branch, everybody's happy. :)
-- brion
On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Wed, Sep 25, 2013 at 2:53 PM, Chad innocentkiller@gmail.com wrote:
So in the interest of keeping our branches from expanding forever I'm thinking we should stop creating new branches for each deploy cycle.
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches now...that's 172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important.
Instead, I'm thinking we should keep like three wmf branches. Let's call them wmf-foo, wmf-bar and wmf-baz for purposes of this e-mail, we can bikeshed later. We'd basically be having the two active branches we have now, plus the previous branch we deployed. When we start a new cycle, the "old" branch becomes the branch new branch, merging everything from master like we do when making a new branch.
It seems to me that reusing branch names could get real confusing...
Indeed.
And so on and so forth. When creating the new branch we can tag the old one
in the same wmf/1.22wmf29 format so it's there for posterity. We could delete all the old branches and turn them into tags.
We could also do exactly that when retiring branches from production, without changing the naming schema. Transfer the branch tip to a tag, delete the branch, everybody's happy. :)
I actually like this idea a lot and it's way less confusing than my idea. Unless anyone's got any objections I'm going to go ahead and do this for all the 1.20 and 1.21 wmf branches.
-Chad
On Wed, Sep 25, 2013 at 3:46 PM, Chad innocentkiller@gmail.com wrote:
I actually like this idea a lot and it's way less confusing than my idea. Unless anyone's got any objections I'm going to go ahead and do this for all the 1.20 and 1.21 wmf branches.
Sounds good to me.
Roan
On 26.09.2013, 2:46 Chad wrote:
On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber bvibber@wikimedia.org wrote:
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches now...that's 172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important.
I always look it up at http://noc.wikimedia.org/conf/highlight.php?file=wikiversions.dat
On Wed, Sep 25, 2013 at 4:01 PM, Max Semenik maxsem.wiki@gmail.com wrote:
On 26.09.2013, 2:46 Chad wrote:
On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber bvibber@wikimedia.org
wrote:
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches
now...that's
172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important.
I always look it up at http://noc.wikimedia.org/conf/highlight.php?file=wikiversions.dat
You can, and you can also use `mwversionsinuse` on the cluster. When I'm on the command line and wanting to merge to a deployment branch I'd rather not have to switch to my browser or SSH in if I can get the info right there...I'm lazy :)
-Chad
Le 26/09/13 00:46, Chad a écrit :
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches now...that's 172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important.
We could simply delete the old branches after a few deployment cycles. If we want to keep the reference for history purposes, would tagging the tip of it be enough ?
If you find yourself struggling to find out the last 2 wmf branches, you can write a tiny script to sort and filter the branches, keeping only the last two.
On Thu, Sep 26, 2013 at 1:09 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 26/09/13 00:46, Chad a écrit :
What's actually the problem with expanding branches?
To me at least, it makes it harder to see what's actually deployed at a given time. Try `git branch -r` on core. We're at 86 branches
now...that's
172 if you've got two remotes. It's only going to get worse and it'll be progressively harder to spot what's important.
We could simply delete the old branches after a few deployment cycles. If we want to keep the reference for history purposes, would tagging the tip of it be enough ?
Yep that was Brion's idea. I've already done it for all the 1.20wmfNN and 1.21wmfNN releases.
-Chad
wikitech-l@lists.wikimedia.org