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 17:02:16 GMT
To clarify, because this all sounds slightly crazy, fauxton was merged
at a time when all the definition of this was still in flux, so it
doesn’t quite match what we want to do from now on. In the future,
if something is not advertisable, it does’t go into master or a
release branch.

This is an exception of sorts.


On Aug 7, 2013, at 18:52 , Jan Lehnardt <> wrote:

> I think fauxton is “shippable”, so it should stay in master and 1.4.x
> (and thus 1.4.0), we just don’t advertise it, because we don’t want
> people to get the wrong impression.
> I took it as a given that that is going to be the way because we never
> discussed backing fauxton out of master and I am surprised that just
> happened. No harm done though, but we shouldn’t invent new procedures
> on the fly, as Noah explains.
> Jan
> --
> On Aug 7, 2013, at 18:44 , 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

View raw message