On Wed, Sep 25, 2013 at 3:01 PM, Roan Kattouw <roan.katt...@gmail.com>wrote:
> On Wed, Sep 25, 2013 at 2:53 PM, Chad <innocentkil...@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
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
