incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 19:06:19 GMT

On Aug 7, 2013, at 20:54 , Russell Branca <> 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.


> -Russell
> On Wed, Aug 7, 2013 at 6:04 PM, Noah Slater <> 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 <> wrote:
>>> On Wed, Aug 7, 2013 at 6:44 PM, Noah Slater <> 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

View raw message