We merged Fauxton into master for two reasons, 1) it was functionally working and in a place where we've kept it in a working state, and 2) the branches had diverged by 6 or 7 months and was becoming unwieldily.
The primary motivation for not including Fauxton in 1.4 is that we're only a few weeks from having the new UI in place (see COUCHDB-1829 and Sue's branch), and I think we should wait to ship until we've got everything in place. It's not "unshippable", I just think we should get it right the first time. -Russell On Wed, Aug 7, 2013 at 6:04 PM, Noah Slater <nsla...@apache.org> wrote: > As Jan points out. This is an odd situation to end up in. But we can still > clean it up properly. :) > > Dirkjan, as the release manager for 1.4.0, you should consider yourself > deputised to make the call on this. If you think that fauxton isn't > shippable, then that is fine, but we should back it out of master, and > recut the 1.4.x branch. > > On IRC you mentioned that removing it from the 1.4.x branch was a shortcut. > I'm all for process shortcuts, but in this instance, it's not a shortcut. > Because the actual problem turns out to be that our release manager thinks > master contains unshippable code. > > Which is fine. Your call. :) But we need to clean this mess up properly. > Which means moving it to a feature branch. > > > On 7 August 2013 17:59, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > > > On Wed, Aug 7, 2013 at 6:44 PM, Noah Slater <nsla...@apache.org> wrote: > > > 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. > > > > This is still weird for me, but it is what we agreed to. > > > > > 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. > > > > Saying I think this is important is cutting it short a little. :) I do > > see a difference between the process we want and the outcome we want. > > If the process has gone off the path we wanted for some reason, I > > don't agree we have to backtrace all the way to where we went wrong > > and move forward again to do it right. Instead, I think we can take a > > shortcut to make sure we get the outcome we want, and try to be better > > about our processes going forward. > > > > > 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. > > > > Okay, so I think shipping gobs of code that aren't wired up to > > anything and have been expressly declared not ready for shipping is > > wrong. We effectively put this whole directory of stuff in the tarball > > that's known not to be functional or, in any case, good enough to > > release as something that's accessible to users... that's pretty crazy > > to me. > > > > So, I prefer (2). But, my point is that it should be fine to take a > > really pretty small shortcut to get there from the current state of > > we-did-something-wrong-a-few-weeks-ago. > > > > > 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.) > > > > I argue that the workflow was already broken before I did anything > > today, because Fauxton wasn't shippable (in any meaningful sense, i.e. > > other than including the code in the tarball). And so we need some > > kind of process to clean that up. > > > > Cheers, > > > > Dirkjan > > > > > > -- > Noah Slater > https://twitter.com/nslater >
