Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of chewbranca@gmail.com
 designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAFUSCh9jtithKn7oBeFUmftqMk3+N+YLL46Hbp9KYRrU-rGNcw@mail.gmail.com>
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>
Date: Mon, 18 Mar 2013 15:06:58 -0700
Message-ID: 
 <CAFUSCh9OU5uh9jQm=NGcd-bhMO-g_zi7=EV1W=3Lyh3KdEcqBw@mail.gmail.com>
Subject: Re: Merging the fauxton branch into master
From: Russell Branca <chewbranca@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=14dae93b5e362fb07f04d83a3508

--14dae93b5e362fb07f04d83a3508
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2013 at 3:04 PM, Russell Branca <chewbranca@gmail.com>wrote=
:

> On Mon, Mar 18, 2013 at 2:37 PM, Jan Lehnardt <jan@apache.org> wrote:
>
>>
>> On Mar 18, 2013, at 22:32 , Russell Branca <chewbranca@apache.org> wrote=
:
>>
>> > On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <jan@apache.org> wrote:
>> >
>> >>
>> >> On Mar 18, 2013, at 21:06 , Russell Branca <chewbranca@apache.org>
>> wrote:
>> >>
>> >>> Last week I noticed the fauxton branch and master branch have drifte=
d
>> >> 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.
>> >>
>> >> Regular rebasing should make parallel branches manageable, or am I
>> missing
>> >> something?
>> >>
>> >
>> > Regular rebasing will keep the branches synchronized, but it will
>> rewrite
>> > the history underneath peoples' feet. I moved my initial rebase over t=
o
>> the
>> > fauxton-rebase branch to avoid messing with anyone currently working i=
n
>> 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 o=
f
>> > 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.
>>
>> Fair enough :)
>>
>>
>> >>> If there are no objections I would like to bring the fauxton-rebase
>> >> branch
>> >>> into master to simplify development workflow and keeping both branch=
es
>> >>> updated.
>> >>
>> >>
>> >> No objection per se, just:
>> >>
>> >> - Since master is poised to be the 1.4.x release branch and before lo=
ng
>> >> the
>> >>   1.4.0 release, is Fauxton in good shape to be released? If not as t=
he
>> >> final
>> >>   replacement of Futon, at least as a preview alongside the regular
>> Futon?
>> >>
>> >
>> > 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 wo=
rk
>> > reasonably well, and the more eyes we can get on it the better.
>>
>> 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.
>>
>
> 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 o=
f
> functionality still not built, but the only blocker in terms of
> functionality I see, is adding an auth module, as right now Fauxton assum=
es
> 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.
>
>
>> If yes, let=92s master it!
>>
>>
> Let's do it!!
>
>
>> >> - Can we double check that all the legal stuff is taken care of?
>> >>
>> >
>> > 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.
>>
>> Cool, we should consider this blocking for the merge to master, just
>> so we are entirely clean for the next release.
>>
>
> Agreed 100%, I'll get that resolved before we make any changes with the
> branches.
>
>
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
>
> -Russell
>


Oh, one more little merge blocker, we should get the build working in the
fauxton branch before bringing it into master. One of the tasks is not
falling back to using settings.json.default and is blowing up the build,
will be a simple fix.


-Russell

--14dae93b5e362fb07f04d83a3508--