couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Do we release src/fauxton?
Date Wed, 07 Aug 2013 16:44:24 GMT

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

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