Devs, In "[1.4] Shipping Fauxton" we agreed to not ship Fauxton.
But this leaves us in a bit of a pickle, because the code is on master. And part of our agreed-upon-but-not-documented Git workflow is that master is always shippable. Another part of our agreed-upon-but-not-documented Git workflow is that major and minor releases are cut from master, or a new release branch that mirrors master. Dirkjan has removed src/fauxton from the 1.4.x, which was recently cut from master. But this, to me, is a problem. It breaks the Git workflow agreement. Because now, we're implicitly saying that master is not shippable. Because we had to cut from it, and then remove a thing that we didn't want to ship. Dirkjan thinks this is unimportant. Because you could just remove src/fauxton from master, cut the 1.4.x branch, and then add it back a few seconds later and say "this is for 1.5.x". And the Git workflow agreement wouldn't be broken. But I think he's wrong, because the agreement is that master is always shippable. So you couldn't just add fauxton back. Because we've just said fauxton is not shippable. So what I actually think Dirkjan is saying is that src/fauxon should be on a feature branch, and not on master. And if that's the case, then fine, but we need to actually do that. We shouldn't leave it on master, and just remove it by hand from any release branches we cut in the meantime. That's sloppy, and it messes with the Git workflow promise we've agreed to but not documented. So, I actually think there are two perspectives here: 1) Master is shippable. It doesn't matter that the fauxton code is on it, because it doesn't effect the user. (Garren has confirmed this for me.) If this is your perspective, then we fix up the Makefile on master, cut 1.4.x master again, and we ship with the fauxton code in the tarball. 2) Master is not shippable. The fauxton code should be removed, and only merged back in once we're happy with it being shipped. (Where being shipped means being included in the tarball, even if it's not activated, or visible for users.) In which case, remove it, put it back on a branch. Then cut 1.4.x master again, and we ship 1.4.0 without any of the fauxton code. I am happy with both options. I think I prefer (1), but if someone wants to go to the effort of (2), then I am okay with that too. What I'm not okay with, however, is breaking our agreed-upon-but-not-documented Git workflow that says that master is always shippable, and that major and minor releases branches are cut from master. (And yep, of course, we make changes to the release branches. But these should be very minimal, and/or backports.) Interested to know what the rest of you think. (And thanks to Dirkjan for suffering my irritability and lack of patience on IRC.) Love and kisses, -- Noah Slater https://twitter.com/nslater
