Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Merging the fauxton branch into master
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: 
 <CAFUSCh9jtithKn7oBeFUmftqMk3+N+YLL46Hbp9KYRrU-rGNcw@mail.gmail.com>
Date: Mon, 18 Mar 2013 23:07:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E17F0E91-8B04-409A-8035-34352AC9D5B4@apache.org>
References: 
 <CAFUSCh-7S12mPXzq29XGotyNOnm45Ez4qWukJu3hbpUnzBuwYw@mail.gmail.com>
 <845C4203-C647-49B6-B7CC-58D40306CAFF@apache.org>
 <CAFUSCh_XSiyKo=-MkCJq8_zsOW4113t66hthgcH37f1-tU0_5A@mail.gmail.com>
 <939710E1-1AD7-45A7-A5B5-1035F42BBCB4@apache.org>
 <CAFUSCh9jtithKn7oBeFUmftqMk3+N+YLL46Hbp9KYRrU-rGNcw@mail.gmail.com>
To: dev@couchdb.apache.org


On Mar 18, 2013, at 23:04 , Russell Branca <chewbranca@gmail.com> wrote:

> On Mon, Mar 18, 2013 at 2:37 PM, Jan Lehnardt <jan@apache.org> wrote:
>=20
>>=20
>> On Mar 18, 2013, at 22:32 , Russell Branca <chewbranca@apache.org> =
wrote:
>>=20
>>> On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <jan@apache.org> =
wrote:
>>>=20
>>>>=20
>>>> On Mar 18, 2013, at 21:06 , Russell Branca <chewbranca@apache.org>
>> wrote:
>>>>=20
>>>>> Last week I noticed the fauxton branch and master branch have =
drifted
>>>> quite
>>>>> apart, and are a couple hundred commits different in either =
direction.
>> I
>>>>> created a branch 'fauxton-rebase' [1] that is the fauxton rebased =
on
>> top
>>>> of
>>>>> the laster master as of friday.
>>>>=20
>>>> Regular rebasing should make parallel branches manageable, or am I
>> missing
>>>> something?
>>>>=20
>>>=20
>>> Regular rebasing will keep the branches synchronized, but it will =
rewrite
>>> the history underneath peoples' feet. I moved my initial rebase over =
to
>> the
>>> fauxton-rebase branch to avoid messing with anyone currently working =
in
>> the
>>> fauxton branch. I don't mind having a parallel branch for Fauxton, =
and I
>>> can take care of bringing in the latest changes, but if we go that =
route
>> I
>>> would prefer to do merges rather than rebases given we have a number =
of
>>> people working on the branch now. I know how some people feel about =
doing
>>> merges ;-) so I figured the best bet was to just throw everything in
>> master
>>> and dodge the problem entirely. If anyone else has a better =
suggestion,
>> I'm
>>> happy to hear it.
>>=20
>> Fair enough :)
>>=20
>>=20
>>>>> If there are no objections I would like to bring the =
fauxton-rebase
>>>> branch
>>>>> into master to simplify development workflow and keeping both =
branches
>>>>> updated.
>>>>=20
>>>>=20
>>>> No objection per se, just:
>>>>=20
>>>> - Since master is poised to be the 1.4.x release branch and before =
long
>>>> the
>>>>  1.4.0 release, is Fauxton in good shape to be released? If not as =
the
>>>> final
>>>>  replacement of Futon, at least as a preview alongside the regular
>> Futon?
>>>>=20
>>>=20
>>> Right now Fauxton is self contained and isolated from Futon, it =
lives at
>>> /_utils/fauxton/index.html so both can be run in parallel. Its =
definitely
>>> not in feature parity with Futon yet, but the things that are there =
work
>>> reasonably well, and the more eyes we can get on it the better.
>>=20
>> So would you say shipping Fauxton as a =93PREVIEW=94 or =
=93EXPERIMENTAL=94 in 1.4.0
>> is sensible? I=92d like to leave this decision with the Fauxton devs.
>>=20
>=20
> Yeah I would like to bring it as Preview or Experimental release =
assuming
> none of the Fauxton devs or anyone else has an objection. This would
> obviously be a what you see is what you get type of release, with a =
lot of
> functionality still not built, but the only blocker in terms of
> functionality I see, is adding an auth module, as right now Fauxton =
assumes
> you're in admin party. I created COUCHDB-1715 to cover this. The =
relevant
> building blocks are in place to add auth, so this should be relatively
> straightforward.
>=20
>=20
>> If yes, let=92s master it!
>>=20
>>=20
> Let's do it!!

Excellent! :D

>=20
>=20
>>>> - Can we double check that all the legal stuff is taken care of?
>>>>=20
>>>=20
>>> Good call, I still have COUCHDB-1710 open to update LICENSE with the
>>> relevant dependency license info. I'll take care of that today or
>> tomorrow.
>>=20
>> Cool, we should consider this blocking for the merge to master, just
>> so we are entirely clean for the next release.
>>=20
>=20
> Agreed 100%, I'll get that resolved before we make any changes with =
the
> branches.
>=20
>=20
>>=20
>> Cheers
>> Jan
>> --
>>=20
>>=20
>>=20
>=20
> -Russell