On Wed, Sep 25, 2013 at 3:18 PM, Brion Vibber <[email protected]> wrote:
> On Wed, Sep 25, 2013 at 2:53 PM, Chad <[email protected]> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
