Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (athena.apache.org: local policy)
From: Jan Lehnardt <jan@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_170DEED7-CAA5-4F45-8090-5040C7F61256";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <6ED6C932-43C3-477A-A9C1-C533E70B9E5C@apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Do we release src/fauxton?
Date: Wed, 7 Aug 2013 18:52:40 +0200
References: 
 <CAPaJBx47G5-chL44Fh_cvSFyPrw9aNsqmUrwLexrhsQHA3eKZw@mail.gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: 
 <CAPaJBx47G5-chL44Fh_cvSFyPrw9aNsqmUrwLexrhsQHA3eKZw@mail.gmail.com>

--Apple-Mail=_170DEED7-CAA5-4F45-8090-5040C7F61256
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I think fauxton is =93shippable=94, so it should stay in master and =
1.4.x
(and thus 1.4.0), we just don=92t advertise it, because we don=92t 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=92t invent new procedures
on the fly, as Noah explains.

Jan
--


On Aug 7, 2013, at 18:44 , Noah Slater <nslater@apache.org> wrote:

> Devs,
>=20
> In "[1.4] Shipping Fauxton" we agreed to not ship Fauxton.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> So, I actually think there are two perspectives here:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.)
>=20
> Interested to know what the rest of you think.
>=20
> (And thanks to Dirkjan for suffering my irritability and lack of =
patience
> on IRC.)
>=20
> Love and kisses,
>=20
> --=20
> Noah Slater
> https://twitter.com/nslater


--Apple-Mail=_170DEED7-CAA5-4F45-8090-5040C7F61256
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlICe1kACgkQ7KW8t7uWVrCltgCfdOU5TKmJ84SSEONF2CcwiIgL
2CsAoKNZgcYm2+segI917m0/zDDbPKhQ
=0esU
-----END PGP SIGNATURE-----

--Apple-Mail=_170DEED7-CAA5-4F45-8090-5040C7F61256--