On 7 August 2013 18:44, Noah Slater <nsla...@apache.org> wrote: > 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
