You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Russell Branca <ch...@apache.org> on 2013/03/18 21:06:34 UTC
Merging the fauxton branch into master
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.
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.
-Russell
[1]
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/fauxton-rebase
Re: Merging the fauxton branch into master
Posted by Noah Slater <ns...@apache.org>.
Please also make sure NOTICE is updated appropriately.
On 19 March 2013 04:37, Russell Branca <ch...@gmail.com> wrote:
> On Mon, Mar 18, 2013 at 6:25 PM, Ryan Ramage <ry...@gmail.com>
> wrote:
>
> > > 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
> > >
> >
> >
> > I think I fixed it here.
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=57164b918f2fe8635201e37dcf5e5a3485eab50b
> >
>
> Might be a slightly different issue, but the build is still failing and it
> looks json file related:
> https://travis-ci.org/apache/couchdb/builds/5612908
>
>
> -Russell
>
--
NS
Re: Merging the fauxton branch into master
Posted by Russell Branca <ch...@gmail.com>.
On Mon, Mar 18, 2013 at 6:25 PM, Ryan Ramage <ry...@gmail.com> wrote:
> > 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
> >
>
>
> I think I fixed it here.
>
> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=57164b918f2fe8635201e37dcf5e5a3485eab50b
>
Might be a slightly different issue, but the build is still failing and it
looks json file related: https://travis-ci.org/apache/couchdb/builds/5612908
-Russell
Re: Merging the fauxton branch into master
Posted by Ryan Ramage <ry...@gmail.com>.
> 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
>
I think I fixed it here.
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=57164b918f2fe8635201e37dcf5e5a3485eab50b
Re: Merging the fauxton branch into master
Posted by Russell Branca <ch...@gmail.com>.
On Mon, Mar 18, 2013 at 3:04 PM, Russell Branca <ch...@gmail.com>wrote:
> On Mon, Mar 18, 2013 at 2:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Mar 18, 2013, at 22:32 , Russell Branca <ch...@apache.org> wrote:
>>
>> > On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> >
>> >>
>> >> On Mar 18, 2013, at 21:06 , Russell Branca <ch...@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
Re: Merging the fauxton branch into master
Posted by Jan Lehnardt <ja...@apache.org>.
On Mar 18, 2013, at 23:04 , Russell Branca <ch...@gmail.com> wrote:
> On Mon, Mar 18, 2013 at 2:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Mar 18, 2013, at 22:32 , Russell Branca <ch...@apache.org> wrote:
>>
>>> On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>>
>>>> On Mar 18, 2013, at 21:06 , Russell Branca <ch...@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
Re: Merging the fauxton branch into master
Posted by Russell Branca <ch...@gmail.com>.
On Mon, Mar 18, 2013 at 2:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Mar 18, 2013, at 22:32 , Russell Branca <ch...@apache.org> wrote:
>
> > On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >>
> >> On Mar 18, 2013, at 21:06 , Russell Branca <ch...@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
Re: Merging the fauxton branch into master
Posted by Ryan Ramage <ry...@gmail.com>.
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.
>
> If yes, let’s master it!
>
>
+1 from me.
Re: Merging the fauxton branch into master
Posted by Simon Metson <si...@cloudant.com>.
+1 from me. We'll need to do some work to integrate it into the build process (hopefully more testing than changing things) but other than that I don't see a reason to not get it out there.
On Monday, 18 March 2013 at 21:37, Jan Lehnardt wrote:
> 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.
Re: Merging the fauxton branch into master
Posted by Jan Lehnardt <ja...@apache.org>.
On Mar 18, 2013, at 22:32 , Russell Branca <ch...@apache.org> wrote:
> On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Mar 18, 2013, at 21:06 , Russell Branca <ch...@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.
If yes, let’s master 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.
Cheers
Jan
--
Re: Merging the fauxton branch into master
Posted by Russell Branca <ch...@apache.org>.
On Mon, Mar 18, 2013 at 2:07 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Mar 18, 2013, at 21:06 , Russell Branca <ch...@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.
>
> > 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.
> - 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.
>
> * * *
>
> I’m very happy to see all the Fauxton progress!
>
Same here!! Its exciting to see the community activity really starting to
pick up with Fauxton, very cool! I'm going to send out a more general
Fauxton update this week, but I wanted to get the branch stuff sorted one
way or another.
>
> Best
> Jan
> --
>
>
-Russell
Re: Merging the fauxton branch into master
Posted by Jan Lehnardt <ja...@apache.org>.
On Mar 18, 2013, at 21:06 , Russell Branca <ch...@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?
> 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?
- Can we double check that all the legal stuff is taken care of?
* * *
I’m very happy to see all the Fauxton progress!
Best
Jan
--