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:04:35 GMT
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

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