Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (nike.apache.org: local policy)
From: Jan Lehnardt <jan@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_1A2B272C-BDF2-476A-AA54-70ACF9E48634";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <5BF489BE-A4AA-4B46-BE91-41A154C027CE@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 19:02:16 +0200
References: 
 <CAPaJBx47G5-chL44Fh_cvSFyPrw9aNsqmUrwLexrhsQHA3eKZw@mail.gmail.com>
 <6ED6C932-43C3-477A-A9C1-C533E70B9E5C@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <6ED6C932-43C3-477A-A9C1-C533E70B9E5C@apache.org>

--Apple-Mail=_1A2B272C-BDF2-476A-AA54-70ACF9E48634
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

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=92t quite match what we want to do from now on. In the future,
if something is not advertisable, it does=92t go into master or a
release branch.

This is an exception of sorts.

Jan
--

On Aug 7, 2013, at 18:52 , Jan Lehnardt <jan@apache.org> wrote:

> 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.
>=20
> 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.
>=20
> Jan
> --
>=20
>=20
>=20
> On Aug 7, 2013, at 18:44 , Noah Slater <nslater@apache.org> wrote:
>=20
>> 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
>=20


--Apple-Mail=_1A2B272C-BDF2-476A-AA54-70ACF9E48634
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

iEYEARECAAYFAlICfZgACgkQ7KW8t7uWVrAjTQCeNi6OpMYZeEaTSz+k5HKfQ2mT
YaEAoKV4DhDdjNpDnBWVX+S8agQCQQXH
=TJwz
-----END PGP SIGNATURE-----

--Apple-Mail=_1A2B272C-BDF2-476A-AA54-70ACF9E48634--