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=_8BECA226-DBDB-4A9C-A77D-399AAFEBA092";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <ACCF7BE5-A61F-4903-A229-C7E01E401995@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 21:06:19 +0200
References: 
 <CAPaJBx47G5-chL44Fh_cvSFyPrw9aNsqmUrwLexrhsQHA3eKZw@mail.gmail.com>
 <CAKmKYaCRAXh__=njRKDQF+9oCjFF_gZ5TQucRAsaZ7xr6koY_w@mail.gmail.com>
 <CAPaJBx61wwDLv4Oe6ZspW9W+_fcDL3YTZhvfARcbdeEG=r8C+w@mail.gmail.com>
 <CAFUSCh9kvho1msFszg6H1t4FOLdcUFVc27jgaUjBe=rEXh=Tfw@mail.gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: 
 <CAFUSCh9kvho1msFszg6H1t4FOLdcUFVc27jgaUjBe=rEXh=Tfw@mail.gmail.com>

--Apple-Mail=_8BECA226-DBDB-4A9C-A77D-399AAFEBA092
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Aug 7, 2013, at 20:54 , Russell Branca <chewbranca@apache.org> wrote:

> We merged Fauxton into master for two reasons, 1) it was functionally
> working and in a place where we've kept it in a working state, and 2) =
the
> branches had diverged by 6 or 7 months and was becoming unwieldily.
>=20
> The primary motivation for not including Fauxton in 1.4 is that we're =
only
> a few weeks from having the new UI in place (see COUCHDB-1829 and =
Sue's
> branch), and I think we should wait to ship until we've got everything =
in
> place. It's not "unshippable", I just think we should get it right the
> first time.

Hence the trick with including the code, but not mentioning it anywhere.

Jan
--


>=20
>=20
> -Russell
>=20
>=20
>=20
>=20
> On Wed, Aug 7, 2013 at 6:04 PM, Noah Slater <nslater@apache.org> =
wrote:
>=20
>> As Jan points out. This is an odd situation to end up in. But we can =
still
>> clean it up properly. :)
>>=20
>> Dirkjan, as the release manager for 1.4.0, you should consider =
yourself
>> deputised to make the call on this. If you think that fauxton isn't
>> shippable, then that is fine, but we should back it out of master, =
and
>> recut the 1.4.x branch.
>>=20
>> On IRC you mentioned that removing it from the 1.4.x branch was a =
shortcut.
>> I'm all for process shortcuts, but in this instance, it's not a =
shortcut.
>> Because the actual problem turns out to be that our release manager =
thinks
>> master contains unshippable code.
>>=20
>> Which is fine. Your call. :) But we need to clean this mess up =
properly.
>> Which means moving it to a feature branch.
>>=20
>>=20
>> On 7 August 2013 17:59, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
>>=20
>>> On Wed, Aug 7, 2013 at 6:44 PM, Noah Slater <nslater@apache.org> =
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.
>>>>=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
>>> This is still weird for me, but it is what we agreed to.
>>>=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
>>> 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.
>>>=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
>>> 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.
>>>=20
>>> 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.
>>>=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
>>> 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.
>>>=20
>>> Cheers,
>>>=20
>>> Dirkjan
>>>=20
>>=20
>>=20
>>=20
>> --
>> Noah Slater
>> https://twitter.com/nslater
>>=20


--Apple-Mail=_8BECA226-DBDB-4A9C-A77D-399AAFEBA092
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

iEYEARECAAYFAlICmqsACgkQ7KW8t7uWVrDQHgCgyQwgJiHX8F1ycR5/YcxHqFnA
BFAAoIMW+jRb+RPAgstBH0go6+EMf8ul
=vNlY
-----END PGP SIGNATURE-----

--Apple-Mail=_8BECA226-DBDB-4A9C-A77D-399AAFEBA092--