On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
On Wed, Sep 25, 2013 at 2:53 PM, Chad
<innocentkiller(a)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