couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Merging the fauxton branch into master
Date Mon, 18 Mar 2013 22:07:09 GMT

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:
> 
>> 
>> 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!!

Excellent! :D

> 
> 
>>>> - 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


Mime
View raw message