Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Thu, Sep 26, 2013 at 1:09 AM, Antoine Musso 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
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. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 4:01 PM, Max Semenik wrote: > On 26.09.2013, 2:46 Chad wrote: > > > On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber > 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On 26.09.2013, 2:46 Chad wrote: > On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber 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 -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 3:46 PM, Chad 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber wrote: > On Wed, Sep 25, 2013 at 2:53 PM, Chad 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 2:53 PM, Chad 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 3:01 PM, Roan Kattouw wrote:
> On Wed, Sep 25, 2013 at 2:53 PM, Chad 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
On Wed, Sep 25, 2013 at 2:53 PM, Chad 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Killing 1.XXwmfYY branches -- another idea?
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
