incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Do we release src/fauxton?
Date Wed, 07 Aug 2013 16:52:40 GMT
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 <nslater@apache.org> 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
> https://twitter.com/nslater


Mime
View raw message