You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2013/12/06 16:17:03 UTC
Re: Next release planning
On 27 Nov 2013, at 09:37 , Andy Wenk <an...@nms.de> wrote:
> On 26 November 2013 17:10, Benjamin Young <by...@bigbluehat.com> wrote:
>
>> This is a nit...maybe...but can we be sure that `_utils/fauxton` and
>> `_utils/fauxton/` both work? :)
>>
>> Would prevent "rock in shoe" sort of frustrations. :)
>>
>
> true :) but that would mean you are not allowed to create a database named
> fauxton which would be requested via _utils/fauxton/
>
> This has already been discussed on IRC and the "solution" was imo more or
> less to wait till fauxton will replace futon. Then you will call it via
> well known _utils/.
There are no discussions on IRC that are binding. If any of this happens,
please make sure that dev@ is informed. This is important to ensure
transparency of the development process/
I don’t see why `/_utils/fauxton/` would collide with a database called
`fauxton` as that would live at `/_fauxton`, but I might be missing something
subtle.
Best
Jan
--
>
> Cheers
>
> Andy
>
>
>>
>> Thanks!
>>
>>
>> On 11/21/13, 3:24 AM, Garren Smith wrote:
>>
>>> Hi All,
>>>
>>> Some changes to Fauxton that will be in the next release are:
>>> * Change from CodeMirror to Ace Editor
>>> * Firefox and IE improvements - IE is still ongoing (Reluctantly)
>>> * Docs can be expanded and collapsed
>>> * Database compaction and View compaction and clean up
>>> * Verify installation implemented
>>> * Database security
>>> * Can use query options on All Docs
>>> * Tons of small fixes and UI improvements
>>>
>>> Sue could you check if I’ve left anything out. There should also be some
>>> more features to still land before we get ready for release.
>>> We would definitely appreciate everyone to try out the Fauxton in 1.5,
>>> and file any bugs they notice.
>>>
>>> Cheers
>>> Garren
>>>
>>>
>>> On 20 November 2013 at 2:37:31 PM, Klaus Trainer (klaus_trainer@posteo.de)
>>> wrote:
>>>
>>> A new feature ready to be reviewed and that I'd love to see in 1.6.0:
>>> https://issues.apache.org/jira/browse/COUCHDB-1923
>>>
>>> Klaus
>>>
>>>
>>> On 11/20/2013 11:57 AM, Dirkjan Ochtman wrote:
>>>
>>>> So we're about half-way through our release window again.
>>>> Any cool stuff we have for a 1.6.0 release? Or this going to be a more
>>>> minor 1.5.1?
>>>> I think I could be the RM again if no one else wants it.
>>>> Cheers,
>>>> Dirkjan
>>>>
>>>>
>>> - signature.asc, 919 bytes
>>>
>>
>>
>
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> http://www.couchdb-buch.de
> http://www.pg-praxisbuch.de
>
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
Re: Next release planning
Posted by Benjamin Young <by...@bigbluehat.com>.
On 12/12/13, 11:52 AM, Alexander Shorin wrote:
> On Thu, Dec 12, 2013 at 8:41 PM, Benjamin Young <by...@bigbluehat.com> wrote:
>> On 12/6/13, 10:17 AM, Jan Lehnardt wrote:
>>> On 27 Nov 2013, at 09:37 , Andy Wenk <an...@nms.de> wrote:
>>>
>>>> On 26 November 2013 17:10, Benjamin Young <by...@bigbluehat.com> wrote:
>>>>
>>>>> This is a nit...maybe...but can we be sure that `_utils/fauxton` and
>>>>> `_utils/fauxton/` both work? :)
>>>>>
>>>>> Would prevent "rock in shoe" sort of frustrations. :)
>>>>>
>>>> true :) but that would mean you are not allowed to create a database
>>>> named
>>>> fauxton which would be requested via _utils/fauxton/
>>>>
>>>> This has already been discussed on IRC and the "solution" was imo more or
>>>> less to wait till fauxton will replace futon. Then you will call it via
>>>> well known _utils/.
>>> There are no discussions on IRC that are binding. If any of this happens,
>>> please make sure that dev@ is informed. This is important to ensure
>>> transparency of the development process/
>>>
>>> I don’t see why `/_utils/fauxton/` would collide with a database called
>>> `fauxton` as that would live at `/_fauxton`, but I might be missing
>>> something
>>> subtle.
>>
>> First, thanks for taking the rock out of the shoe, Jan. :D
>>
>> Second, why was /_utils/fauxton(/) chosen over /_fauxton?
>>
>> Was there a mailing list conversation about it?
>>
>> Seems adding that to a config (even now) would have been simpler than all
>> the custom handling.
> IIRC the motivation was to not create too much _magic resources, to
> not confuse people even if Fauxton ships on right of experimental
> feature.
Makes sense. :) thanks.
>
> --
> ,,,^..^,,,
Re: Next release planning
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Dec 12, 2013 at 8:41 PM, Benjamin Young <by...@bigbluehat.com> wrote:
> On 12/6/13, 10:17 AM, Jan Lehnardt wrote:
>>
>> On 27 Nov 2013, at 09:37 , Andy Wenk <an...@nms.de> wrote:
>>
>>> On 26 November 2013 17:10, Benjamin Young <by...@bigbluehat.com> wrote:
>>>
>>>> This is a nit...maybe...but can we be sure that `_utils/fauxton` and
>>>> `_utils/fauxton/` both work? :)
>>>>
>>>> Would prevent "rock in shoe" sort of frustrations. :)
>>>>
>>> true :) but that would mean you are not allowed to create a database
>>> named
>>> fauxton which would be requested via _utils/fauxton/
>>>
>>> This has already been discussed on IRC and the "solution" was imo more or
>>> less to wait till fauxton will replace futon. Then you will call it via
>>> well known _utils/.
>>
>> There are no discussions on IRC that are binding. If any of this happens,
>> please make sure that dev@ is informed. This is important to ensure
>> transparency of the development process/
>>
>> I don’t see why `/_utils/fauxton/` would collide with a database called
>> `fauxton` as that would live at `/_fauxton`, but I might be missing
>> something
>> subtle.
>
>
> First, thanks for taking the rock out of the shoe, Jan. :D
>
> Second, why was /_utils/fauxton(/) chosen over /_fauxton?
>
> Was there a mailing list conversation about it?
>
> Seems adding that to a config (even now) would have been simpler than all
> the custom handling.
IIRC the motivation was to not create too much _magic resources, to
not confuse people even if Fauxton ships on right of experimental
feature.
--
,,,^..^,,,
Re: Next release planning
Posted by Benjamin Young <by...@bigbluehat.com>.
On 12/6/13, 10:17 AM, Jan Lehnardt wrote:
> On 27 Nov 2013, at 09:37 , Andy Wenk <an...@nms.de> wrote:
>
>> On 26 November 2013 17:10, Benjamin Young <by...@bigbluehat.com> wrote:
>>
>>> This is a nit...maybe...but can we be sure that `_utils/fauxton` and
>>> `_utils/fauxton/` both work? :)
>>>
>>> Would prevent "rock in shoe" sort of frustrations. :)
>>>
>> true :) but that would mean you are not allowed to create a database named
>> fauxton which would be requested via _utils/fauxton/
>>
>> This has already been discussed on IRC and the "solution" was imo more or
>> less to wait till fauxton will replace futon. Then you will call it via
>> well known _utils/.
> There are no discussions on IRC that are binding. If any of this happens,
> please make sure that dev@ is informed. This is important to ensure
> transparency of the development process/
>
> I don’t see why `/_utils/fauxton/` would collide with a database called
> `fauxton` as that would live at `/_fauxton`, but I might be missing something
> subtle.
First, thanks for taking the rock out of the shoe, Jan. :D
Second, why was /_utils/fauxton(/) chosen over /_fauxton?
Was there a mailing list conversation about it?
Seems adding that to a config (even now) would have been simpler than
all the custom handling.
Just wondering.
>
> Best
> Jan
> --
>
>
>> Cheers
>>
>> Andy
>>
>>
>>> Thanks!
>>>
>>>
>>> On 11/21/13, 3:24 AM, Garren Smith wrote:
>>>
>>>> Hi All,
>>>>
>>>> Some changes to Fauxton that will be in the next release are:
>>>> * Change from CodeMirror to Ace Editor
>>>> * Firefox and IE improvements - IE is still ongoing (Reluctantly)
>>>> * Docs can be expanded and collapsed
>>>> * Database compaction and View compaction and clean up
>>>> * Verify installation implemented
>>>> * Database security
>>>> * Can use query options on All Docs
>>>> * Tons of small fixes and UI improvements
>>>>
>>>> Sue could you check if I’ve left anything out. There should also be some
>>>> more features to still land before we get ready for release.
>>>> We would definitely appreciate everyone to try out the Fauxton in 1.5,
>>>> and file any bugs they notice.
>>>>
>>>> Cheers
>>>> Garren
>>>>
>>>>
>>>> On 20 November 2013 at 2:37:31 PM, Klaus Trainer (klaus_trainer@posteo.de)
>>>> wrote:
>>>>
>>>> A new feature ready to be reviewed and that I'd love to see in 1.6.0:
>>>> https://issues.apache.org/jira/browse/COUCHDB-1923
>>>>
>>>> Klaus
>>>>
>>>>
>>>> On 11/20/2013 11:57 AM, Dirkjan Ochtman wrote:
>>>>
>>>>> So we're about half-way through our release window again.
>>>>> Any cool stuff we have for a 1.6.0 release? Or this going to be a more
>>>>> minor 1.5.1?
>>>>> I think I could be the RM again if no one else wants it.
>>>>> Cheers,
>>>>> Dirkjan
>>>>>
>>>>>
>>>> - signature.asc, 919 bytes
>>>>
>>>
>>
>> --
>> Andy Wenk
>> Hamburg - Germany
>> RockIt!
>>
>> http://www.couchdb-buch.de
>> http://www.pg-praxisbuch.de
>>
>> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
Re: Next release planning
Posted by Andy Wenk <an...@nms.de>.
On 10 December 2013 13:56, Garren Smith <ga...@apache.org> wrote:
>
>
> On 10 December 2013 at 2:55:22 PM, Alexander Shorin (kxepal@gmail.com)
> wrote:
>
> On Tue, Dec 10, 2013 at 4:46 PM, Andy Wenk <an...@nms.de> wrote:
> > On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
> >
> >> > Yes, but the URL is `/_utils/fauxton/`, isn’t it?
> >> >
> >>
> >>
> >> It is indeed
> >>
> >
> > Unfortunately I was not able to find the conversation we had. But I do
> > remember that there has been the question, why we cannot have both URL's
> to
> > access Fauxton:
> >
> > /_utils/fauxton
> > /_utils/fauxton/
> >
> > And I do remember, that there has been the info, that we can only use
> the
> > second version - what is indeed annoying. If there are no problems with
> > both (what I assume is what you are both saying), then we should create
> a
> > Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
>
> Correct me if I'm wrong, but I see that CouchDB handles both /_utils
> and /_utils/ only because of special case in http handler:
>
> https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd_misc_handlers.erl#L66
>
> While this issue isn't annoying, I think the better fix is to get
> ready Fauxton and replace Futon with it instead of having yet another
> redirect case in handler's code (:
> I agree.
>
+1 :)
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
Re: Next release planning
Posted by Garren Smith <ga...@apache.org>.
On 10 December 2013 at 2:55:22 PM, Alexander Shorin (kxepal@gmail.com) wrote:
On Tue, Dec 10, 2013 at 4:46 PM, Andy Wenk <an...@nms.de> wrote:
> On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
>
>> > Yes, but the URL is `/_utils/fauxton/`, isn’t it?
>> >
>>
>>
>> It is indeed
>>
>
> Unfortunately I was not able to find the conversation we had. But I do
> remember that there has been the question, why we cannot have both URL's to
> access Fauxton:
>
> /_utils/fauxton
> /_utils/fauxton/
>
> And I do remember, that there has been the info, that we can only use the
> second version - what is indeed annoying. If there are no problems with
> both (what I assume is what you are both saying), then we should create a
> Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
Correct me if I'm wrong, but I see that CouchDB handles both /_utils
and /_utils/ only because of special case in http handler:
https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd_misc_handlers.erl#L66
While this issue isn't annoying, I think the better fix is to get
ready Fauxton and replace Futon with it instead of having yet another
redirect case in handler's code (:
I agree.
--
,,,^..^,,,
Re: Next release planning
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Dec 10, 2013 at 8:48 PM, Jan Lehnardt <ja...@apache.org> wrote:
> On 10 Dec 2013, at 17:31 , Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On 10 Dec 2013, at 13:54 , Alexander Shorin <kx...@gmail.com> wrote:
>>
>>> On Tue, Dec 10, 2013 at 4:46 PM, Andy Wenk <an...@nms.de> wrote:
>>>> On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
>>>>
>>>>>> Yes, but the URL is `/_utils/fauxton/`, isn’t it?
>>>>>>
>>>>>
>>>>>
>>>>> It is indeed
>>>>>
>>>>
>>>> Unfortunately I was not able to find the conversation we had. But I do
>>>> remember that there has been the question, why we cannot have both URL's to
>>>> access Fauxton:
>>>>
>>>> /_utils/fauxton
>>>> /_utils/fauxton/
>>>>
>>>> And I do remember, that there has been the info, that we can only use the
>>>> second version - what is indeed annoying. If there are no problems with
>>>> both (what I assume is what you are both saying), then we should create a
>>>> Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
>>>
>>> Correct me if I'm wrong, but I see that CouchDB handles both /_utils
>>> and /_utils/ only because of special case in http handler:
>>> https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd_misc_handlers.erl#L66
>>> While this issue isn't annoying, I think the better fix is to get
>>> ready Fauxton and replace Futon with it instead of having yet another
>>> redirect case in handler's code (:
>>
>> I assume that at least for the next release Fauxton will not be ready and we haven’t yet resolved how to actually do the transition (https://issues.apache.org/jira/browse/COUCHDB-1954) I strongly suggest we do in fact add another special clause to that function to support both /_utils/fauxton/ and /_utils/fauxton
>
> A commit for your review: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blobdiff;f=src/couchdb/couch_httpd_misc_handlers.erl;h=cd7b4287c3a1ea598362570dad50d2ba7447dbc4;hp=96a05c6d63beee32151cc1de47666cb2500958fe;hb=de20e995;hpb=0f3735887b80d6e057abade2703c99f81cd92ca5
It works! Looks good for me.
--
,,,^..^,,,
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Dec 2013, at 17:31 , Jan Lehnardt <ja...@apache.org> wrote:
>
> On 10 Dec 2013, at 13:54 , Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Tue, Dec 10, 2013 at 4:46 PM, Andy Wenk <an...@nms.de> wrote:
>>> On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
>>>
>>>>> Yes, but the URL is `/_utils/fauxton/`, isn’t it?
>>>>>
>>>>
>>>>
>>>> It is indeed
>>>>
>>>
>>> Unfortunately I was not able to find the conversation we had. But I do
>>> remember that there has been the question, why we cannot have both URL's to
>>> access Fauxton:
>>>
>>> /_utils/fauxton
>>> /_utils/fauxton/
>>>
>>> And I do remember, that there has been the info, that we can only use the
>>> second version - what is indeed annoying. If there are no problems with
>>> both (what I assume is what you are both saying), then we should create a
>>> Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
>>
>> Correct me if I'm wrong, but I see that CouchDB handles both /_utils
>> and /_utils/ only because of special case in http handler:
>> https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd_misc_handlers.erl#L66
>> While this issue isn't annoying, I think the better fix is to get
>> ready Fauxton and replace Futon with it instead of having yet another
>> redirect case in handler's code (:
>
> I assume that at least for the next release Fauxton will not be ready and we haven’t yet resolved how to actually do the transition (https://issues.apache.org/jira/browse/COUCHDB-1954) I strongly suggest we do in fact add another special clause to that function to support both /_utils/fauxton/ and /_utils/fauxton
A commit for your review: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blobdiff;f=src/couchdb/couch_httpd_misc_handlers.erl;h=cd7b4287c3a1ea598362570dad50d2ba7447dbc4;hp=96a05c6d63beee32151cc1de47666cb2500958fe;hb=de20e995;hpb=0f3735887b80d6e057abade2703c99f81cd92ca5
Best
Jan
--
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Dec 2013, at 13:54 , Alexander Shorin <kx...@gmail.com> wrote:
> On Tue, Dec 10, 2013 at 4:46 PM, Andy Wenk <an...@nms.de> wrote:
>> On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
>>
>>>> Yes, but the URL is `/_utils/fauxton/`, isn’t it?
>>>>
>>>
>>>
>>> It is indeed
>>>
>>
>> Unfortunately I was not able to find the conversation we had. But I do
>> remember that there has been the question, why we cannot have both URL's to
>> access Fauxton:
>>
>> /_utils/fauxton
>> /_utils/fauxton/
>>
>> And I do remember, that there has been the info, that we can only use the
>> second version - what is indeed annoying. If there are no problems with
>> both (what I assume is what you are both saying), then we should create a
>> Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
>
> Correct me if I'm wrong, but I see that CouchDB handles both /_utils
> and /_utils/ only because of special case in http handler:
> https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd_misc_handlers.erl#L66
> While this issue isn't annoying, I think the better fix is to get
> ready Fauxton and replace Futon with it instead of having yet another
> redirect case in handler's code (:
I assume that at least for the next release Fauxton will not be ready and we haven’t yet resolved how to actually do the transition (https://issues.apache.org/jira/browse/COUCHDB-1954) I strongly suggest we do in fact add another special clause to that function to support both /_utils/fauxton/ and /_utils/fauxton
Best
Jan
--
Re: Next release planning
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Dec 10, 2013 at 4:46 PM, Andy Wenk <an...@nms.de> wrote:
> On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
>
>> > Yes, but the URL is `/_utils/fauxton/`, isn’t it?
>> >
>>
>>
>> It is indeed
>>
>
> Unfortunately I was not able to find the conversation we had. But I do
> remember that there has been the question, why we cannot have both URL's to
> access Fauxton:
>
> /_utils/fauxton
> /_utils/fauxton/
>
> And I do remember, that there has been the info, that we can only use the
> second version - what is indeed annoying. If there are no problems with
> both (what I assume is what you are both saying), then we should create a
> Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
Correct me if I'm wrong, but I see that CouchDB handles both /_utils
and /_utils/ only because of special case in http handler:
https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd_misc_handlers.erl#L66
While this issue isn't annoying, I think the better fix is to get
ready Fauxton and replace Futon with it instead of having yet another
redirect case in handler's code (:
--
,,,^..^,,,
Re: Next release planning
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
You mean, generate the full Fauxton build?
That would be good, though we badly need to fix things for the next
release so that we don't have to do this stuff as a separate step.
Cheers,
Dirkjan
On Wed, Dec 11, 2013 at 7:44 AM, Garren Smith <ga...@apache.org> wrote:
> Hi Dirkjan,
>
> I can make a release on Saturday morning if that is not to late?
>
> Cheers
> Garren
>
> On 10 December 2013 at 7:38:20 PM, Dirkjan Ochtman (dirkjan@ochtman.nl)
> wrote:
>
> On Tue, Dec 10, 2013 at 1:51 PM, Garren Smith <ga...@apache.org> wrote:
>> When is Dirkjan going to cut this release?
>
> I never got any response to this:
>
> On Fri, Dec 6, 2013 at 10:46 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> I think I talked to Garren a little bit on IRC. It would be really
>> helpful to get this answered? At worst, we'd need someone to rebuild
>> the built copy of Fauxton we keep in the tree for release purposed.
>> Can someone take care of that?
>>
>> Sorry I didn't respond to this sooner, life has been keeping me busy
>> again. So my window for today has passed. The weekend is pretty busy,
>> so once Fauxton build clears I'll try to find some slot to come up
>> with an artefact.
>
> Cheers,
>
> Dirkjan
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
On 05 Jan 2014, at 19:24 , Alexander Shorin <kx...@gmail.com> wrote:
> On Sun, Jan 5, 2014 at 4:24 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> -1 on COUCHDB-1988 & 89. Neither of them are critical and require fiddling with autotools which are notorious to get wrong. As noted on the commit thread, 1989 currently fails make distcheck. And 1988 has no patch. Let’s not do these just before a release, but just after one, so we have some more time to catch problems.
>
> I'd like to suggest take at least Posix tar fix from 1989 branch:
> http://git-wip-us.apache.org/repos/asf/couchdb/commit/12c9ee07
>
> There was questions about this bug on #couchdb from users that built
> packages for, iirc, RHEL, or something. For those case they had fixed
> it by local patch, but I feel better have such in upstream. I could
> recover related discussion logs if needed.
No need to hold the release for this, IMHO.
Jan
--
Re: Next release planning
Posted by Alexander Shorin <kx...@gmail.com>.
On Sun, Jan 5, 2014 at 4:24 PM, Jan Lehnardt <ja...@apache.org> wrote:
> -1 on COUCHDB-1988 & 89. Neither of them are critical and require fiddling with autotools which are notorious to get wrong. As noted on the commit thread, 1989 currently fails make distcheck. And 1988 has no patch. Let’s not do these just before a release, but just after one, so we have some more time to catch problems.
I'd like to suggest take at least Posix tar fix from 1989 branch:
http://git-wip-us.apache.org/repos/asf/couchdb/commit/12c9ee07
There was questions about this bug on #couchdb from users that built
packages for, iirc, RHEL, or something. For those case they had fixed
it by local patch, but I feel better have such in upstream. I could
recover related discussion logs if needed.
--
,,,^..^,,,
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
On 05 Jan 2014, at 13:59 , Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Jan 5, 2014 at 1:24 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On 05 Jan 2014, at 10:56 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
>>
>>> On Sun, Jan 5, 2014 at 10:41 AM, Benoit Chesneau <bc...@gmail.com>
>> wrote:
>>>> I would like to include in this release the following tickets if it's
>> not
>>>> too late:
>>>>
>>>> COUCHDB-1960
>>>> COUCHDB-1988
>>>> COUCHDB-1989
>>>
>>> I have no objection, but I'd prefer not to hold off the release for
>>> it. That said, I probably won't have time to cut the artefact today,
>>> so you can land them.
>>
>> +0 on COUCHDB-1960 (mini-review on the ticket)
>>
>
> well at least this code had a review.
Yeah, this is good to go, but it is not worth holding the release for this :)
Best
Jan
--
>
>
>>
>> -1 on COUCHDB-1988 & 89. Neither of them are critical and require fiddling
>> with autotools which are notorious to get wrong. As noted on the commit
>> thread, 1989 currently fails make distcheck. And 1988 has no patch. Let’s
>> not do these just before a release, but just after one, so we have some
>> more time to catch problems.
>>
>
> ok.
Re: Next release planning
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Jan 5, 2014 at 1:24 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 05 Jan 2014, at 10:56 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
> > On Sun, Jan 5, 2014 at 10:41 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> >> I would like to include in this release the following tickets if it's
> not
> >> too late:
> >>
> >> COUCHDB-1960
> >> COUCHDB-1988
> >> COUCHDB-1989
> >
> > I have no objection, but I'd prefer not to hold off the release for
> > it. That said, I probably won't have time to cut the artefact today,
> > so you can land them.
>
> +0 on COUCHDB-1960 (mini-review on the ticket)
>
well at least this code had a review.
>
> -1 on COUCHDB-1988 & 89. Neither of them are critical and require fiddling
> with autotools which are notorious to get wrong. As noted on the commit
> thread, 1989 currently fails make distcheck. And 1988 has no patch. Let’s
> not do these just before a release, but just after one, so we have some
> more time to catch problems.
>
ok.
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
On 05 Jan 2014, at 10:56 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Sun, Jan 5, 2014 at 10:41 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>> I would like to include in this release the following tickets if it's not
>> too late:
>>
>> COUCHDB-1960
>> COUCHDB-1988
>> COUCHDB-1989
>
> I have no objection, but I'd prefer not to hold off the release for
> it. That said, I probably won't have time to cut the artefact today,
> so you can land them.
+0 on COUCHDB-1960 (mini-review on the ticket)
-1 on COUCHDB-1988 & 89. Neither of them are critical and require fiddling with autotools which are notorious to get wrong. As noted on the commit thread, 1989 currently fails make distcheck. And 1988 has no patch. Let’s not do these just before a release, but just after one, so we have some more time to catch problems.
In general I’d say master is ready for branching & release and Dirkjan should just cut and go as soon as he finds time. Everything else can go into 1.6.1 four weeks from now.
Best
Jan
--
Re: Next release planning
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Jan 5, 2014 at 10:41 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> I would like to include in this release the following tickets if it's not
> too late:
>
> COUCHDB-1960
> COUCHDB-1988
> COUCHDB-1989
I have no objection, but I'd prefer not to hold off the release for
it. That said, I probably won't have time to cut the artefact today,
so you can land them.
Cheers,
Dirkjan
Re: Next release planning
Posted by Benoit Chesneau <bc...@gmail.com>.
I would like to include in this release the following tickets if it's not
too late:
COUCHDB-1960
COUCHDB-1988
COUCHDB-1989
The two last one will ease the merge later and I already use them in the
(for now private) rcouch branch before moving all the code around
- benoit
On Fri, Dec 13, 2013 at 10:54 AM, Garren Smith <ga...@apache.org> wrote:
> Hi Jan,
>
> I’ve updated the Fauxton readme (src/fauxton/readme) with the required
> steps.
>
> Cheers
> Garren
>
> On 12 December 2013 at 9:32:36 PM, Jan Lehnardt (jan@apache.org) wrote:
>
> Garren, could you share what is needed to build/deploy Fauxton in the way
> you do?
>
> Best
> Jan
> --
>
> On 11 Dec 2013, at 07:44 , Garren Smith <ga...@apache.org> wrote:
>
> > Hi Dirkjan,
> >
> > I can make a release on Saturday morning if that is not to late?
> >
> > Cheers
> > Garren
> >
> > On 10 December 2013 at 7:38:20 PM, Dirkjan Ochtman (dirkjan@ochtman.nl)
> wrote:
> >
> > On Tue, Dec 10, 2013 at 1:51 PM, Garren Smith <ga...@apache.org> wrote:
> >> When is Dirkjan going to cut this release?
> >
> > I never got any response to this:
> >
> > On Fri, Dec 6, 2013 at 10:46 PM, Dirkjan Ochtman <di...@ochtman.nl>
> wrote:
> >> I think I talked to Garren a little bit on IRC. It would be really
> >> helpful to get this answered? At worst, we'd need someone to rebuild
> >> the built copy of Fauxton we keep in the tree for release purposed.
> >> Can someone take care of that?
> >>
> >> Sorry I didn't respond to this sooner, life has been keeping me busy
> >> again. So my window for today has passed. The weekend is pretty busy,
> >> so once Fauxton build clears I'll try to find some slot to come up
> >> with an artefact.
> >
> > Cheers,
> >
> > Dirkjan
>
> - signature.asc, 817 bytes
Re: Next release planning
Posted by Garren Smith <ga...@apache.org>.
Hi Jan,
I’ve updated the Fauxton readme (src/fauxton/readme) with the required steps.
Cheers
Garren
On 12 December 2013 at 9:32:36 PM, Jan Lehnardt (jan@apache.org) wrote:
Garren, could you share what is needed to build/deploy Fauxton in the way you do?
Best
Jan
--
On 11 Dec 2013, at 07:44 , Garren Smith <ga...@apache.org> wrote:
> Hi Dirkjan,
>
> I can make a release on Saturday morning if that is not to late?
>
> Cheers
> Garren
>
> On 10 December 2013 at 7:38:20 PM, Dirkjan Ochtman (dirkjan@ochtman.nl) wrote:
>
> On Tue, Dec 10, 2013 at 1:51 PM, Garren Smith <ga...@apache.org> wrote:
>> When is Dirkjan going to cut this release?
>
> I never got any response to this:
>
> On Fri, Dec 6, 2013 at 10:46 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> I think I talked to Garren a little bit on IRC. It would be really
>> helpful to get this answered? At worst, we'd need someone to rebuild
>> the built copy of Fauxton we keep in the tree for release purposed.
>> Can someone take care of that?
>>
>> Sorry I didn't respond to this sooner, life has been keeping me busy
>> again. So my window for today has passed. The weekend is pretty busy,
>> so once Fauxton build clears I'll try to find some slot to come up
>> with an artefact.
>
> Cheers,
>
> Dirkjan
- signature.asc, 817 bytes
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
Garren, could you share what is needed to build/deploy Fauxton in the way you do?
Best
Jan
--
On 11 Dec 2013, at 07:44 , Garren Smith <ga...@apache.org> wrote:
> Hi Dirkjan,
>
> I can make a release on Saturday morning if that is not to late?
>
> Cheers
> Garren
>
> On 10 December 2013 at 7:38:20 PM, Dirkjan Ochtman (dirkjan@ochtman.nl) wrote:
>
> On Tue, Dec 10, 2013 at 1:51 PM, Garren Smith <ga...@apache.org> wrote:
>> When is Dirkjan going to cut this release?
>
> I never got any response to this:
>
> On Fri, Dec 6, 2013 at 10:46 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> I think I talked to Garren a little bit on IRC. It would be really
>> helpful to get this answered? At worst, we'd need someone to rebuild
>> the built copy of Fauxton we keep in the tree for release purposed.
>> Can someone take care of that?
>>
>> Sorry I didn't respond to this sooner, life has been keeping me busy
>> again. So my window for today has passed. The weekend is pretty busy,
>> so once Fauxton build clears I'll try to find some slot to come up
>> with an artefact.
>
> Cheers,
>
> Dirkjan
Re: Next release planning
Posted by Garren Smith <ga...@apache.org>.
Hi Dirkjan,
I can make a release on Saturday morning if that is not to late?
Cheers
Garren
On 10 December 2013 at 7:38:20 PM, Dirkjan Ochtman (dirkjan@ochtman.nl) wrote:
On Tue, Dec 10, 2013 at 1:51 PM, Garren Smith <ga...@apache.org> wrote:
> When is Dirkjan going to cut this release?
I never got any response to this:
On Fri, Dec 6, 2013 at 10:46 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> I think I talked to Garren a little bit on IRC. It would be really
> helpful to get this answered? At worst, we'd need someone to rebuild
> the built copy of Fauxton we keep in the tree for release purposed.
> Can someone take care of that?
>
> Sorry I didn't respond to this sooner, life has been keeping me busy
> again. So my window for today has passed. The weekend is pretty busy,
> so once Fauxton build clears I'll try to find some slot to come up
> with an artefact.
Cheers,
Dirkjan
Re: Next release planning
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Tue, Dec 10, 2013 at 1:51 PM, Garren Smith <ga...@apache.org> wrote:
> When is Dirkjan going to cut this release?
I never got any response to this:
On Fri, Dec 6, 2013 at 10:46 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> I think I talked to Garren a little bit on IRC. It would be really
> helpful to get this answered? At worst, we'd need someone to rebuild
> the built copy of Fauxton we keep in the tree for release purposed.
> Can someone take care of that?
>
> Sorry I didn't respond to this sooner, life has been keeping me busy
> again. So my window for today has passed. The weekend is pretty busy,
> so once Fauxton build clears I'll try to find some slot to come up
> with an artefact.
Cheers,
Dirkjan
Re: Next release planning
Posted by Garren Smith <ga...@apache.org>.
When is Dirkjan going to cut this release? For the Fauxton side of things we are busy working hard to get a new version done by the end of the week which will have a fair amount of UI tweaks and improvements. We still need to integrate the building of Fauxton into the build scripts. So if there is some one able to do that or help us with that, that would be great.
With regards to /_utils/fauxton/ and /_utils/fauxton. I’ve lost track of this conversation. Is it possible to do /_utils/fauxton?
On 10 December 2013 at 2:47:40 PM, Andy Wenk (andy@nms.de) wrote:
On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
> > Yes, but the URL is `/_utils/fauxton/`, isn’t it?
> >
>
>
> It is indeed
>
Unfortunately I was not able to find the conversation we had. But I do
remember that there has been the question, why we cannot have both URL's to
access Fauxton:
/_utils/fauxton
/_utils/fauxton/
And I do remember, that there has been the info, that we can only use the
second version - what is indeed annoying. If there are no problems with
both (what I assume is what you are both saying), then we should create a
Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
Cheers
Andy
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
Re: Next release planning
Posted by Andy Wenk <an...@nms.de>.
On 9 December 2013 13:09, Simon Metson <si...@cloudant.com> wrote:
> > Yes, but the URL is `/_utils/fauxton/`, isn’t it?
> >
>
>
> It is indeed
>
Unfortunately I was not able to find the conversation we had. But I do
remember that there has been the question, why we cannot have both URL's to
access Fauxton:
/_utils/fauxton
/_utils/fauxton/
And I do remember, that there has been the info, that we can only use the
second version - what is indeed annoying. If there are no problems with
both (what I assume is what you are both saying), then we should create a
Jira ticket and fix it. Or we wait till fauxton will become /_utils/ :)
Cheers
Andy
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
Re: Next release planning
Posted by Simon Metson <si...@cloudant.com>.
> Yes, but the URL is `/_utils/fauxton/`, isn’t it?
>
It is indeed
Re: Next release planning
Posted by Jan Lehnardt <ja...@apache.org>.
On 08 Dec 2013, at 16:17 , Andy Wenk <an...@nms.de> wrote:
> On 6 December 2013 16:17, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 27 Nov 2013, at 09:37 , Andy Wenk <an...@nms.de> wrote:
>
> > On 26 November 2013 17:10, Benjamin Young <by...@bigbluehat.com> wrote:
> >
> >> This is a nit...maybe...but can we be sure that `_utils/fauxton` and
> >> `_utils/fauxton/` both work? :)
> >>
> >> Would prevent "rock in shoe" sort of frustrations. :)
> >>
> >
> > true :) but that would mean you are not allowed to create a database named
> > fauxton which would be requested via _utils/fauxton/
> >
> > This has already been discussed on IRC and the "solution" was imo more or
> > less to wait till fauxton will replace futon. Then you will call it via
> > well known _utils/.
>
> There are no discussions on IRC that are binding. If any of this happens,
> please make sure that dev@ is informed. This is important to ensure
> transparency of the development process/
>
> Jan, thanks for pointing me to this.
>
> I don’t see why `/_utils/fauxton/` would collide with a database called
> `fauxton` as that would live at `/_fauxton`, but I might be missing something
> subtle.
>
> I don't get the point here. When calling a database called fauxton, the API call would be sth. like /fauxton/all_docs . Wouldn't that collide with /fauxton as the Webinterface?
Yes, but the URL is `/_utils/fauxton/`, isn’t it?
Best
Jan
--
>
> Cheers
>
> Andy
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> http://www.couchdb-buch.de
> http://www.pg-praxisbuch.de
>
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
Re: Next release planning
Posted by Andy Wenk <an...@nms.de>.
On 6 December 2013 16:17, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 27 Nov 2013, at 09:37 , Andy Wenk <an...@nms.de> wrote:
>
> > On 26 November 2013 17:10, Benjamin Young <by...@bigbluehat.com> wrote:
> >
> >> This is a nit...maybe...but can we be sure that `_utils/fauxton` and
> >> `_utils/fauxton/` both work? :)
> >>
> >> Would prevent "rock in shoe" sort of frustrations. :)
> >>
> >
> > true :) but that would mean you are not allowed to create a database
> named
> > fauxton which would be requested via _utils/fauxton/
> >
> > This has already been discussed on IRC and the "solution" was imo more or
> > less to wait till fauxton will replace futon. Then you will call it via
> > well known _utils/.
>
> There are no discussions on IRC that are binding. If any of this happens,
> please make sure that dev@ is informed. This is important to ensure
> transparency of the development process/
>
Jan, thanks for pointing me to this.
> I don’t see why `/_utils/fauxton/` would collide with a database called
> `fauxton` as that would live at `/_fauxton`, but I might be missing
> something
> subtle.
>
I don't get the point here. When calling a database called fauxton, the API
call would be sth. like /fauxton/all_docs . Wouldn't that collide with
/fauxton as the Webinterface?
Cheers
Andy
--
Andy Wenk
Hamburg - Germany
RockIt!
http://www.couchdb-buch.de
http://www.pg-praxisbuch.de
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588