couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirkjan Ochtman <>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 16:59:15 GMT
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

> 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.



View raw message