couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <chewbra...@gmail.com>
Subject Re: Merging the fauxton branch into master
Date Mon, 18 Mar 2013 22:06:58 GMT
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 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.
>> >>
>> >> 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 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.
>>
>> 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 branches
>> >>> updated.
>> >>
>> >>
>> >> No objection per se, just:
>> >>
>> >> - 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?
>> >>
>> >
>> > 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.
>>
>> So would you say shipping Fauxton as a “PREVIEW” or “EXPERIMENTAL” in
>> 1.4.0
>> is sensible? I’d 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 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.
>
>
>> If yes, let’s 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message