couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ramage <>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 16:54:22 GMT
I am happy with 1) Master is shippable. Leave the Fauxton code in, but do
not advertise it.

Sorry I should have commented on the [1.4 Shipping Fauxton] thread.

On Wed, Aug 7, 2013 at 10:44 AM, Noah Slater <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message