On Aug 7, 2013, at 20:54 , Russell Branca <[email protected]> wrote:
> 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. Hence the trick with including the code, but not mentioning it anywhere. Jan -- > > > -Russell > > > > > On Wed, Aug 7, 2013 at 6:04 PM, Noah Slater <[email protected]> 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 <[email protected]> wrote: >> >>> On Wed, Aug 7, 2013 at 6:44 PM, Noah Slater <[email protected]> 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 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
