couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 19:51:42 GMT
Weird googleness, this time with comments.

On 7 August 2013 18:59, Dirkjan Ochtman <> wrote:
> 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.

Nicely put.

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

+1 optimise for sanity.

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

+0.8 -- this is the way I see it. Feel free to shoot me down but I am
not fussed if we have code that is not directly user-accessible that's
included in a release. Although we shouldn't make a habit of it.

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

Agree, however I think we crossed the fauxtonic rubicon a while back,
I'd rather not force a huge merge later on for the sake of git branch
purity. We have a merry circus of merges this year and one less branch
of this magnitude is a Good Thing.

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

I'm ok with whatever the RM decides is appropriate. No point in
handing out a pointy hat if you can't wear it at maximal pointiness.
Ultimately we are in a messy situation and I'd go for whatever is Most
Relaxing, ie takes the least effort to sort out.

Finally, it seems like 1.4 is a good line in the sand to draw about
sticking to a branch workflow. I'll bring myself up to date and then
try and write it all up this week.


View raw message