Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Hello,

There's been a regression in the browser test suite.

Building from the 1.2.x branch, the first test, basics, hangs for me.

The end of the logs are:

[info] [<0.1509.0>] Apache CouchDB has started on http://127.0.0.1:5984/
[info] [<0.1603.0>] 127.0.0.1 - - GET / 200
[info] [<0.1603.0>] 127.0.0.1 - - GET
/test_suite_db/0?rev=3-cac36b6fd7e2c7347b3147626c8cfdaf 200
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db 201
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db 201
[info] [<0.1603.0>] 127.0.0.1 - - GET /test_suite_db/oppossum 200
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/newdoc 201
[info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_db/doc-does-not-exist
404
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/goldfish 500
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/zebrafish 500
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/mudfish 500
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/tastyfish 500
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/bar 400
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_bulk_docs 400
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_all_docs 400
[info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_all_docs 400
[info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_db/?rev=foobarbaz 400
[info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_foobar/ 200
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_foobar 201
[info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_foobar/doc1 201
[info] [<0.1603.0>] 127.0.0.1 - - POST
/test_suite_foobar/_ensure_full_commit 201
[info] [<0.1603.0>] 127.0.0.1 - - GET /test_suite_foobar/ 200
[info] [<0.1603.0>] 127.0.0.1 - - POST /_restart 200
Apache CouchDB 1.2.0 (LogLevel=info) is starting.
Apache CouchDB has started. Time to relax.
[info] [<0.1673.0>] Apache CouchDB has started on http://127.0.0.1:5984/
[info] [<0.1767.0>] 127.0.0.1 - - GET / 200

This happens consistently. (Though the log looks different)

Firefox 11.0, private browsing turned on and off, OS X 10.7.3, 11" MBA.

Thanks,

N

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Wed, Mar 21, 2012 at 13:58, Bob Dionne <di...@dionne-associates.com> wrote:
> make check runs here Randall, R15B

Still running. If someone buys me an SSD I'll run the tests more often ;)

Re: Problems blocking 1.2.0

[Bob Dionne <di...@dionne-associates.com>]

make check runs here Randall, R15B
On Mar 21, 2012, at 4:42 PM, Randall Leeds wrote:

> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
> 
>> Have you added the appropriate entries in NEWS and CHANGES?
>> 
> 
> I have just now. Running make check so I can give you the green light.
> Would appreciate if anyone else would do the same.
> 
> 
>> 
>> On Wed, Mar 21, 2012 at 8:08 PM, Randall Leeds <randall.leeds@gmail.com
>>> wrote:
>> 
>>> On Mar 21, 2012 11:54 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
>>>> 
>>>> Thanks! Do they relate to a ticket? How should I summarise the changes?
>>> 
>>> They amount to improvement on COUCHDB-966, and could be summarized as
>> "more
>>> descriptive messages for file-related error conditions".
>>> 
>> 

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Just checking:

https://issues.apache.org/jira/browse/COUCHDB-1445

This is still marked as unresolved.

Could someone close the ticket with any additional comment needed?

On Sat, Mar 24, 2012 at 11:10 AM, Jan Lehnardt <ja...@apache.org> wrote:

>
> On Mar 23, 2012, at 21:44 , Noah Slater wrote:
>
> > Thank you.
>
> Seconded, thanks :)
>
> I ran the current 1.2.x branch through its paces and make distcheck checks
> out
> and I got the browser test suite to succeed in Firefox 11 in private
> browsing
> mode, albeit only on the second try. In the first attempt the replicator_db
> test failed and left the server in a state with admins configured, so all
> subsequent tests failed because of that. I believe this is a known issue
> that
> we should look into, but that is not blocking.
>
> Release away, Noah :)
>
> Cheers
> Jan
> --
>
>
> >
> > On Fri, Mar 23, 2012 at 7:46 PM, Randall Leeds <randall.leeds@gmail.com
> >wrote:
> >
> >> On Fri, Mar 23, 2012 at 07:26, Robert Newson <rn...@apache.org>
> wrote:
> >>> I'm revising that, benoit rightly suggests adding a create_if_missing
> >>> option which would work the way randall thought create worked.
> >>
> >> With Benoit and Bob's help, we decided that log at debug was fine and
> >> I added a log for all uncaught exceptions that would return 500s to
> >> the client to be sure things don't go unnoticed by the admin in
> >> production.
> >>
> >> Should be unblocked now for 1.2 release.
> >>
> >> -R
> >>
> >>>
> >>> B.
> >>>
> >>> On 23 March 2012 14:08, Robert Newson <rn...@apache.org> wrote:
> >>>>
> >>
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=1d13adcdcc9e31b80c8c2c4d84bddbe8452e20ec
> >>>>
> >>>> On 23 March 2012 14:04, Noah Slater <ns...@tumbolia.org> wrote:
> >>>>> \o/
> >>>>>
> >>>>> On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org>
> >> wrote:
> >>>>>
> >>>>>> Working on it.
> >>>>>>
> >>>>>> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
> >>>>>>> I am available tonight to try and ship 1.2.0. Will we be ready by
> >> then?
> >>>>>>>
> >>>>>>> On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rnewson@apache.org
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Randall,
> >>>>>>>>
> >>>>>>>> I could write a whole thing here but I'll cut it short and simply
> >>>>>>>> apologise for any offense you have taken, it was not intended. My
> >>>>>>>> 'chastisement' was intended humorously, but you were essentially
> >>>>>>>> saying that your fix should have worked if only [create] worked
> the
> >>>>>>>> way you imagined it did rather than how it does (which implies you
> >>>>>>>> didn't try it).
> >>>>>>>>
> >>>>>>>> I'll state again that logging at debug level is not a great
> >> solution.
> >>>>>>>> We should log at error level *except* when auto-creating the
> _users
> >>>>>>>> and _replicator dbs. It's a more involved fix, but I think it's
> >> worth
> >>>>>>>> it.
> >>>>>>>>
> >>>>>>>> B.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com>
> >> wrote:
> >>>>>>>>> On Fri, Mar 23, 2012 at 06:15, Robert Newson <rnewson@apache.org
> >>>
> >>>>>> wrote:
> >>>>>>>>>> I'm also -1 on your revised solution. We go to the trouble of
> >>>>>>>>>> carefully logging and formatting these errors and then log them
> >> at a
> >>>>>>>>>> level that approximately no one ever runs at (debug is far too
> >> noisy
> >>>>>>>>>> to use in production, for instance).
> >>>>>>>>>
> >>>>>>>>> s/we/I/, and that's the point of debug.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> B.
> >>>>>>>>>>
> >>>>>>>>>> On 23 March 2012 13:14, Robert Newson <rn...@apache.org>
> >> wrote:
> >>>>>>>>>>> " Is there a good reason why we don't honor
> >>>>>>>>>>> the create option in the way I expected?"
> >>>>>>>>>>>
> >>>>>>>>>>> Is there a good reason you committed a fix to a release branch
> >>>>>> without
> >>>>>>>>>>> testing it?
> >>>>>>>>>
> >>>>>>>>> Are you referring to the different fix which I quickly reverted
> >> on
> >>>>>>>>> 1.1.x? I did test that I didn't get your spurious error report,
> >> but
> >>>>>>>>> tested more before committing to 1.2.x, caught my oversight,
> >> reverted,
> >>>>>>>>> and offered the only solution which is non-invasive.
> >>>>>>>>>
> >>>>>>>>> Is there a good reason you'd prefer to chastise me than to
> >> answer my
> >>>>>>>>> question? I woke up at 5:30am and checked my e-mail because my
> >>>>>>>>> roommate happened to be in there already. I decided I felt guilty
> >>>>>>>>> enough about a spurious log message and cared enough about
> >> shipping
> >>>>>>>>> 1.2 to stay awake and investigate. I committed a fix because I
> >> was
> >>>>>>>>> trying to be _helpful_.
> >>>>>>>>>
> >>>>>>>>> I'm asleep for a few hours. Happy to discuss process when I
> >> return.
> >>>>>>>>
> >>>>>>
> >>
>
>

Re: Problems blocking 1.2.0

[Jan Lehnardt <ja...@apache.org>]

On Mar 23, 2012, at 21:44 , Noah Slater wrote:

> Thank you.

Seconded, thanks :)

I ran the current 1.2.x branch through its paces and make distcheck checks out
and I got the browser test suite to succeed in Firefox 11 in private browsing
mode, albeit only on the second try. In the first attempt the replicator_db
test failed and left the server in a state with admins configured, so all
subsequent tests failed because of that. I believe this is a known issue that
we should look into, but that is not blocking.

Release away, Noah :)

Cheers
Jan
-- 


> 
> On Fri, Mar 23, 2012 at 7:46 PM, Randall Leeds <ra...@gmail.com>wrote:
> 
>> On Fri, Mar 23, 2012 at 07:26, Robert Newson <rn...@apache.org> wrote:
>>> I'm revising that, benoit rightly suggests adding a create_if_missing
>>> option which would work the way randall thought create worked.
>> 
>> With Benoit and Bob's help, we decided that log at debug was fine and
>> I added a log for all uncaught exceptions that would return 500s to
>> the client to be sure things don't go unnoticed by the admin in
>> production.
>> 
>> Should be unblocked now for 1.2 release.
>> 
>> -R
>> 
>>> 
>>> B.
>>> 
>>> On 23 March 2012 14:08, Robert Newson <rn...@apache.org> wrote:
>>>> 
>> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=1d13adcdcc9e31b80c8c2c4d84bddbe8452e20ec
>>>> 
>>>> On 23 March 2012 14:04, Noah Slater <ns...@tumbolia.org> wrote:
>>>>> \o/
>>>>> 
>>>>> On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org>
>> wrote:
>>>>> 
>>>>>> Working on it.
>>>>>> 
>>>>>> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>> I am available tonight to try and ship 1.2.0. Will we be ready by
>> then?
>>>>>>> 
>>>>>>> On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Randall,
>>>>>>>> 
>>>>>>>> I could write a whole thing here but I'll cut it short and simply
>>>>>>>> apologise for any offense you have taken, it was not intended. My
>>>>>>>> 'chastisement' was intended humorously, but you were essentially
>>>>>>>> saying that your fix should have worked if only [create] worked the
>>>>>>>> way you imagined it did rather than how it does (which implies you
>>>>>>>> didn't try it).
>>>>>>>> 
>>>>>>>> I'll state again that logging at debug level is not a great
>> solution.
>>>>>>>> We should log at error level *except* when auto-creating the _users
>>>>>>>> and _replicator dbs. It's a more involved fix, but I think it's
>> worth
>>>>>>>> it.
>>>>>>>> 
>>>>>>>> B.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com>
>> wrote:
>>>>>>>>> On Fri, Mar 23, 2012 at 06:15, Robert Newson <rnewson@apache.org
>>> 
>>>>>> wrote:
>>>>>>>>>> I'm also -1 on your revised solution. We go to the trouble of
>>>>>>>>>> carefully logging and formatting these errors and then log them
>> at a
>>>>>>>>>> level that approximately no one ever runs at (debug is far too
>> noisy
>>>>>>>>>> to use in production, for instance).
>>>>>>>>> 
>>>>>>>>> s/we/I/, and that's the point of debug.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> B.
>>>>>>>>>> 
>>>>>>>>>> On 23 March 2012 13:14, Robert Newson <rn...@apache.org>
>> wrote:
>>>>>>>>>>> " Is there a good reason why we don't honor
>>>>>>>>>>> the create option in the way I expected?"
>>>>>>>>>>> 
>>>>>>>>>>> Is there a good reason you committed a fix to a release branch
>>>>>> without
>>>>>>>>>>> testing it?
>>>>>>>>> 
>>>>>>>>> Are you referring to the different fix which I quickly reverted
>> on
>>>>>>>>> 1.1.x? I did test that I didn't get your spurious error report,
>> but
>>>>>>>>> tested more before committing to 1.2.x, caught my oversight,
>> reverted,
>>>>>>>>> and offered the only solution which is non-invasive.
>>>>>>>>> 
>>>>>>>>> Is there a good reason you'd prefer to chastise me than to
>> answer my
>>>>>>>>> question? I woke up at 5:30am and checked my e-mail because my
>>>>>>>>> roommate happened to be in there already. I decided I felt guilty
>>>>>>>>> enough about a spurious log message and cared enough about
>> shipping
>>>>>>>>> 1.2 to stay awake and investigate. I committed a fix because I
>> was
>>>>>>>>> trying to be _helpful_.
>>>>>>>>> 
>>>>>>>>> I'm asleep for a few hours. Happy to discuss process when I
>> return.
>>>>>>>> 
>>>>>> 
>> 

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Thank you.

On Fri, Mar 23, 2012 at 7:46 PM, Randall Leeds <ra...@gmail.com>wrote:

> On Fri, Mar 23, 2012 at 07:26, Robert Newson <rn...@apache.org> wrote:
> > I'm revising that, benoit rightly suggests adding a create_if_missing
> > option which would work the way randall thought create worked.
>
> With Benoit and Bob's help, we decided that log at debug was fine and
> I added a log for all uncaught exceptions that would return 500s to
> the client to be sure things don't go unnoticed by the admin in
> production.
>
> Should be unblocked now for 1.2 release.
>
> -R
>
> >
> > B.
> >
> > On 23 March 2012 14:08, Robert Newson <rn...@apache.org> wrote:
> >>
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=1d13adcdcc9e31b80c8c2c4d84bddbe8452e20ec
> >>
> >> On 23 March 2012 14:04, Noah Slater <ns...@tumbolia.org> wrote:
> >>> \o/
> >>>
> >>> On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org>
> wrote:
> >>>
> >>>> Working on it.
> >>>>
> >>>> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
> >>>> > I am available tonight to try and ship 1.2.0. Will we be ready by
> then?
> >>>> >
> >>>> > On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org>
> >>>> wrote:
> >>>> >
> >>>> >> Randall,
> >>>> >>
> >>>> >> I could write a whole thing here but I'll cut it short and simply
> >>>> >> apologise for any offense you have taken, it was not intended. My
> >>>> >> 'chastisement' was intended humorously, but you were essentially
> >>>> >> saying that your fix should have worked if only [create] worked the
> >>>> >> way you imagined it did rather than how it does (which implies you
> >>>> >> didn't try it).
> >>>> >>
> >>>> >> I'll state again that logging at debug level is not a great
> solution.
> >>>> >> We should log at error level *except* when auto-creating the _users
> >>>> >> and _replicator dbs. It's a more involved fix, but I think it's
> worth
> >>>> >> it.
> >>>> >>
> >>>> >> B.
> >>>> >>
> >>>> >>
> >>>> >> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com>
> wrote:
> >>>> >> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rnewson@apache.org
> >
> >>>> wrote:
> >>>> >> >> I'm also -1 on your revised solution. We go to the trouble of
> >>>> >> >> carefully logging and formatting these errors and then log them
> at a
> >>>> >> >> level that approximately no one ever runs at (debug is far too
> noisy
> >>>> >> >> to use in production, for instance).
> >>>> >> >
> >>>> >> > s/we/I/, and that's the point of debug.
> >>>> >> >
> >>>> >> >>
> >>>> >> >> B.
> >>>> >> >>
> >>>> >> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org>
> wrote:
> >>>> >> >>> " Is there a good reason why we don't honor
> >>>> >> >>> the create option in the way I expected?"
> >>>> >> >>>
> >>>> >> >>> Is there a good reason you committed a fix to a release branch
> >>>> without
> >>>> >> >>> testing it?
> >>>> >> >
> >>>> >> > Are you referring to the different fix which I quickly reverted
> on
> >>>> >> > 1.1.x? I did test that I didn't get your spurious error report,
> but
> >>>> >> > tested more before committing to 1.2.x, caught my oversight,
> reverted,
> >>>> >> > and offered the only solution which is non-invasive.
> >>>> >> >
> >>>> >> > Is there a good reason you'd prefer to chastise me than to
> answer my
> >>>> >> > question? I woke up at 5:30am and checked my e-mail because my
> >>>> >> > roommate happened to be in there already. I decided I felt guilty
> >>>> >> > enough about a spurious log message and cared enough about
> shipping
> >>>> >> > 1.2 to stay awake and investigate. I committed a fix because I
> was
> >>>> >> > trying to be _helpful_.
> >>>> >> >
> >>>> >> > I'm asleep for a few hours. Happy to discuss process when I
> return.
> >>>> >>
> >>>>
>

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Fri, Mar 23, 2012 at 07:26, Robert Newson <rn...@apache.org> wrote:
> I'm revising that, benoit rightly suggests adding a create_if_missing
> option which would work the way randall thought create worked.

With Benoit and Bob's help, we decided that log at debug was fine and
I added a log for all uncaught exceptions that would return 500s to
the client to be sure things don't go unnoticed by the admin in
production.

Should be unblocked now for 1.2 release.

-R

>
> B.
>
> On 23 March 2012 14:08, Robert Newson <rn...@apache.org> wrote:
>> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=1d13adcdcc9e31b80c8c2c4d84bddbe8452e20ec
>>
>> On 23 March 2012 14:04, Noah Slater <ns...@tumbolia.org> wrote:
>>> \o/
>>>
>>> On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org> wrote:
>>>
>>>> Working on it.
>>>>
>>>> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
>>>> > I am available tonight to try and ship 1.2.0. Will we be ready by then?
>>>> >
>>>> > On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org>
>>>> wrote:
>>>> >
>>>> >> Randall,
>>>> >>
>>>> >> I could write a whole thing here but I'll cut it short and simply
>>>> >> apologise for any offense you have taken, it was not intended. My
>>>> >> 'chastisement' was intended humorously, but you were essentially
>>>> >> saying that your fix should have worked if only [create] worked the
>>>> >> way you imagined it did rather than how it does (which implies you
>>>> >> didn't try it).
>>>> >>
>>>> >> I'll state again that logging at debug level is not a great solution.
>>>> >> We should log at error level *except* when auto-creating the _users
>>>> >> and _replicator dbs. It's a more involved fix, but I think it's worth
>>>> >> it.
>>>> >>
>>>> >> B.
>>>> >>
>>>> >>
>>>> >> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
>>>> >> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org>
>>>> wrote:
>>>> >> >> I'm also -1 on your revised solution. We go to the trouble of
>>>> >> >> carefully logging and formatting these errors and then log them at a
>>>> >> >> level that approximately no one ever runs at (debug is far too noisy
>>>> >> >> to use in production, for instance).
>>>> >> >
>>>> >> > s/we/I/, and that's the point of debug.
>>>> >> >
>>>> >> >>
>>>> >> >> B.
>>>> >> >>
>>>> >> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>>>> >> >>> " Is there a good reason why we don't honor
>>>> >> >>> the create option in the way I expected?"
>>>> >> >>>
>>>> >> >>> Is there a good reason you committed a fix to a release branch
>>>> without
>>>> >> >>> testing it?
>>>> >> >
>>>> >> > Are you referring to the different fix which I quickly reverted on
>>>> >> > 1.1.x? I did test that I didn't get your spurious error report, but
>>>> >> > tested more before committing to 1.2.x, caught my oversight, reverted,
>>>> >> > and offered the only solution which is non-invasive.
>>>> >> >
>>>> >> > Is there a good reason you'd prefer to chastise me than to answer my
>>>> >> > question? I woke up at 5:30am and checked my e-mail because my
>>>> >> > roommate happened to be in there already. I decided I felt guilty
>>>> >> > enough about a spurious log message and cared enough about shipping
>>>> >> > 1.2 to stay awake and investigate. I committed a fix because I was
>>>> >> > trying to be _helpful_.
>>>> >> >
>>>> >> > I'm asleep for a few hours. Happy to discuss process when I return.
>>>> >>
>>>>

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

I'm revising that, benoit rightly suggests adding a create_if_missing
option which would work the way randall thought create worked.

B.

On 23 March 2012 14:08, Robert Newson <rn...@apache.org> wrote:
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=1d13adcdcc9e31b80c8c2c4d84bddbe8452e20ec
>
> On 23 March 2012 14:04, Noah Slater <ns...@tumbolia.org> wrote:
>> \o/
>>
>> On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org> wrote:
>>
>>> Working on it.
>>>
>>> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
>>> > I am available tonight to try and ship 1.2.0. Will we be ready by then?
>>> >
>>> > On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org>
>>> wrote:
>>> >
>>> >> Randall,
>>> >>
>>> >> I could write a whole thing here but I'll cut it short and simply
>>> >> apologise for any offense you have taken, it was not intended. My
>>> >> 'chastisement' was intended humorously, but you were essentially
>>> >> saying that your fix should have worked if only [create] worked the
>>> >> way you imagined it did rather than how it does (which implies you
>>> >> didn't try it).
>>> >>
>>> >> I'll state again that logging at debug level is not a great solution.
>>> >> We should log at error level *except* when auto-creating the _users
>>> >> and _replicator dbs. It's a more involved fix, but I think it's worth
>>> >> it.
>>> >>
>>> >> B.
>>> >>
>>> >>
>>> >> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
>>> >> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org>
>>> wrote:
>>> >> >> I'm also -1 on your revised solution. We go to the trouble of
>>> >> >> carefully logging and formatting these errors and then log them at a
>>> >> >> level that approximately no one ever runs at (debug is far too noisy
>>> >> >> to use in production, for instance).
>>> >> >
>>> >> > s/we/I/, and that's the point of debug.
>>> >> >
>>> >> >>
>>> >> >> B.
>>> >> >>
>>> >> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>>> >> >>> " Is there a good reason why we don't honor
>>> >> >>> the create option in the way I expected?"
>>> >> >>>
>>> >> >>> Is there a good reason you committed a fix to a release branch
>>> without
>>> >> >>> testing it?
>>> >> >
>>> >> > Are you referring to the different fix which I quickly reverted on
>>> >> > 1.1.x? I did test that I didn't get your spurious error report, but
>>> >> > tested more before committing to 1.2.x, caught my oversight, reverted,
>>> >> > and offered the only solution which is non-invasive.
>>> >> >
>>> >> > Is there a good reason you'd prefer to chastise me than to answer my
>>> >> > question? I woke up at 5:30am and checked my e-mail because my
>>> >> > roommate happened to be in there already. I decided I felt guilty
>>> >> > enough about a spurious log message and cared enough about shipping
>>> >> > 1.2 to stay awake and investigate. I committed a fix because I was
>>> >> > trying to be _helpful_.
>>> >> >
>>> >> > I'm asleep for a few hours. Happy to discuss process when I return.
>>> >>
>>>

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=1d13adcdcc9e31b80c8c2c4d84bddbe8452e20ec

On 23 March 2012 14:04, Noah Slater <ns...@tumbolia.org> wrote:
> \o/
>
> On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org> wrote:
>
>> Working on it.
>>
>> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
>> > I am available tonight to try and ship 1.2.0. Will we be ready by then?
>> >
>> > On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org>
>> wrote:
>> >
>> >> Randall,
>> >>
>> >> I could write a whole thing here but I'll cut it short and simply
>> >> apologise for any offense you have taken, it was not intended. My
>> >> 'chastisement' was intended humorously, but you were essentially
>> >> saying that your fix should have worked if only [create] worked the
>> >> way you imagined it did rather than how it does (which implies you
>> >> didn't try it).
>> >>
>> >> I'll state again that logging at debug level is not a great solution.
>> >> We should log at error level *except* when auto-creating the _users
>> >> and _replicator dbs. It's a more involved fix, but I think it's worth
>> >> it.
>> >>
>> >> B.
>> >>
>> >>
>> >> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
>> >> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org>
>> wrote:
>> >> >> I'm also -1 on your revised solution. We go to the trouble of
>> >> >> carefully logging and formatting these errors and then log them at a
>> >> >> level that approximately no one ever runs at (debug is far too noisy
>> >> >> to use in production, for instance).
>> >> >
>> >> > s/we/I/, and that's the point of debug.
>> >> >
>> >> >>
>> >> >> B.
>> >> >>
>> >> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>> >> >>> " Is there a good reason why we don't honor
>> >> >>> the create option in the way I expected?"
>> >> >>>
>> >> >>> Is there a good reason you committed a fix to a release branch
>> without
>> >> >>> testing it?
>> >> >
>> >> > Are you referring to the different fix which I quickly reverted on
>> >> > 1.1.x? I did test that I didn't get your spurious error report, but
>> >> > tested more before committing to 1.2.x, caught my oversight, reverted,
>> >> > and offered the only solution which is non-invasive.
>> >> >
>> >> > Is there a good reason you'd prefer to chastise me than to answer my
>> >> > question? I woke up at 5:30am and checked my e-mail because my
>> >> > roommate happened to be in there already. I decided I felt guilty
>> >> > enough about a spurious log message and cared enough about shipping
>> >> > 1.2 to stay awake and investigate. I committed a fix because I was
>> >> > trying to be _helpful_.
>> >> >
>> >> > I'm asleep for a few hours. Happy to discuss process when I return.
>> >>
>>

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

\o/

On Fri, Mar 23, 2012 at 1:56 PM, Robert Newson <rn...@apache.org> wrote:

> Working on it.
>
> On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
> > I am available tonight to try and ship 1.2.0. Will we be ready by then?
> >
> > On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org>
> wrote:
> >
> >> Randall,
> >>
> >> I could write a whole thing here but I'll cut it short and simply
> >> apologise for any offense you have taken, it was not intended. My
> >> 'chastisement' was intended humorously, but you were essentially
> >> saying that your fix should have worked if only [create] worked the
> >> way you imagined it did rather than how it does (which implies you
> >> didn't try it).
> >>
> >> I'll state again that logging at debug level is not a great solution.
> >> We should log at error level *except* when auto-creating the _users
> >> and _replicator dbs. It's a more involved fix, but I think it's worth
> >> it.
> >>
> >> B.
> >>
> >>
> >> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
> >> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org>
> wrote:
> >> >> I'm also -1 on your revised solution. We go to the trouble of
> >> >> carefully logging and formatting these errors and then log them at a
> >> >> level that approximately no one ever runs at (debug is far too noisy
> >> >> to use in production, for instance).
> >> >
> >> > s/we/I/, and that's the point of debug.
> >> >
> >> >>
> >> >> B.
> >> >>
> >> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
> >> >>> " Is there a good reason why we don't honor
> >> >>> the create option in the way I expected?"
> >> >>>
> >> >>> Is there a good reason you committed a fix to a release branch
> without
> >> >>> testing it?
> >> >
> >> > Are you referring to the different fix which I quickly reverted on
> >> > 1.1.x? I did test that I didn't get your spurious error report, but
> >> > tested more before committing to 1.2.x, caught my oversight, reverted,
> >> > and offered the only solution which is non-invasive.
> >> >
> >> > Is there a good reason you'd prefer to chastise me than to answer my
> >> > question? I woke up at 5:30am and checked my e-mail because my
> >> > roommate happened to be in there already. I decided I felt guilty
> >> > enough about a spurious log message and cared enough about shipping
> >> > 1.2 to stay awake and investigate. I committed a fix because I was
> >> > trying to be _helpful_.
> >> >
> >> > I'm asleep for a few hours. Happy to discuss process when I return.
> >>
>

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

Working on it.

On 23 March 2012 13:54, Noah Slater <ns...@tumbolia.org> wrote:
> I am available tonight to try and ship 1.2.0. Will we be ready by then?
>
> On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org> wrote:
>
>> Randall,
>>
>> I could write a whole thing here but I'll cut it short and simply
>> apologise for any offense you have taken, it was not intended. My
>> 'chastisement' was intended humorously, but you were essentially
>> saying that your fix should have worked if only [create] worked the
>> way you imagined it did rather than how it does (which implies you
>> didn't try it).
>>
>> I'll state again that logging at debug level is not a great solution.
>> We should log at error level *except* when auto-creating the _users
>> and _replicator dbs. It's a more involved fix, but I think it's worth
>> it.
>>
>> B.
>>
>>
>> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
>> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org> wrote:
>> >> I'm also -1 on your revised solution. We go to the trouble of
>> >> carefully logging and formatting these errors and then log them at a
>> >> level that approximately no one ever runs at (debug is far too noisy
>> >> to use in production, for instance).
>> >
>> > s/we/I/, and that's the point of debug.
>> >
>> >>
>> >> B.
>> >>
>> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>> >>> " Is there a good reason why we don't honor
>> >>> the create option in the way I expected?"
>> >>>
>> >>> Is there a good reason you committed a fix to a release branch without
>> >>> testing it?
>> >
>> > Are you referring to the different fix which I quickly reverted on
>> > 1.1.x? I did test that I didn't get your spurious error report, but
>> > tested more before committing to 1.2.x, caught my oversight, reverted,
>> > and offered the only solution which is non-invasive.
>> >
>> > Is there a good reason you'd prefer to chastise me than to answer my
>> > question? I woke up at 5:30am and checked my e-mail because my
>> > roommate happened to be in there already. I decided I felt guilty
>> > enough about a spurious log message and cared enough about shipping
>> > 1.2 to stay awake and investigate. I committed a fix because I was
>> > trying to be _helpful_.
>> >
>> > I'm asleep for a few hours. Happy to discuss process when I return.
>>

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

I am available tonight to try and ship 1.2.0. Will we be ready by then?

On Fri, Mar 23, 2012 at 1:39 PM, Robert Newson <rn...@apache.org> wrote:

> Randall,
>
> I could write a whole thing here but I'll cut it short and simply
> apologise for any offense you have taken, it was not intended. My
> 'chastisement' was intended humorously, but you were essentially
> saying that your fix should have worked if only [create] worked the
> way you imagined it did rather than how it does (which implies you
> didn't try it).
>
> I'll state again that logging at debug level is not a great solution.
> We should log at error level *except* when auto-creating the _users
> and _replicator dbs. It's a more involved fix, but I think it's worth
> it.
>
> B.
>
>
> On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
> > On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org> wrote:
> >> I'm also -1 on your revised solution. We go to the trouble of
> >> carefully logging and formatting these errors and then log them at a
> >> level that approximately no one ever runs at (debug is far too noisy
> >> to use in production, for instance).
> >
> > s/we/I/, and that's the point of debug.
> >
> >>
> >> B.
> >>
> >> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
> >>> " Is there a good reason why we don't honor
> >>> the create option in the way I expected?"
> >>>
> >>> Is there a good reason you committed a fix to a release branch without
> >>> testing it?
> >
> > Are you referring to the different fix which I quickly reverted on
> > 1.1.x? I did test that I didn't get your spurious error report, but
> > tested more before committing to 1.2.x, caught my oversight, reverted,
> > and offered the only solution which is non-invasive.
> >
> > Is there a good reason you'd prefer to chastise me than to answer my
> > question? I woke up at 5:30am and checked my e-mail because my
> > roommate happened to be in there already. I decided I felt guilty
> > enough about a spurious log message and cared enough about shipping
> > 1.2 to stay awake and investigate. I committed a fix because I was
> > trying to be _helpful_.
> >
> > I'm asleep for a few hours. Happy to discuss process when I return.
>

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

Randall,

I could write a whole thing here but I'll cut it short and simply
apologise for any offense you have taken, it was not intended. My
'chastisement' was intended humorously, but you were essentially
saying that your fix should have worked if only [create] worked the
way you imagined it did rather than how it does (which implies you
didn't try it).

I'll state again that logging at debug level is not a great solution.
We should log at error level *except* when auto-creating the _users
and _replicator dbs. It's a more involved fix, but I think it's worth
it.

B.


On 23 March 2012 13:28, Randall Leeds <ra...@gmail.com> wrote:
> On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org> wrote:
>> I'm also -1 on your revised solution. We go to the trouble of
>> carefully logging and formatting these errors and then log them at a
>> level that approximately no one ever runs at (debug is far too noisy
>> to use in production, for instance).
>
> s/we/I/, and that's the point of debug.
>
>>
>> B.
>>
>> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>>> " Is there a good reason why we don't honor
>>> the create option in the way I expected?"
>>>
>>> Is there a good reason you committed a fix to a release branch without
>>> testing it?
>
> Are you referring to the different fix which I quickly reverted on
> 1.1.x? I did test that I didn't get your spurious error report, but
> tested more before committing to 1.2.x, caught my oversight, reverted,
> and offered the only solution which is non-invasive.
>
> Is there a good reason you'd prefer to chastise me than to answer my
> question? I woke up at 5:30am and checked my e-mail because my
> roommate happened to be in there already. I decided I felt guilty
> enough about a spurious log message and cared enough about shipping
> 1.2 to stay awake and investigate. I committed a fix because I was
> trying to be _helpful_.
>
> I'm asleep for a few hours. Happy to discuss process when I return.

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Fri, Mar 23, 2012 at 06:15, Robert Newson <rn...@apache.org> wrote:
> I'm also -1 on your revised solution. We go to the trouble of
> carefully logging and formatting these errors and then log them at a
> level that approximately no one ever runs at (debug is far too noisy
> to use in production, for instance).

s/we/I/, and that's the point of debug.

>
> B.
>
> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>> " Is there a good reason why we don't honor
>> the create option in the way I expected?"
>>
>> Is there a good reason you committed a fix to a release branch without
>> testing it?

Are you referring to the different fix which I quickly reverted on
1.1.x? I did test that I didn't get your spurious error report, but
tested more before committing to 1.2.x, caught my oversight, reverted,
and offered the only solution which is non-invasive.

Is there a good reason you'd prefer to chastise me than to answer my
question? I woke up at 5:30am and checked my e-mail because my
roommate happened to be in there already. I decided I felt guilty
enough about a spurious log message and cared enough about shipping
1.2 to stay awake and investigate. I committed a fix because I was
trying to be _helpful_.

I'm asleep for a few hours. Happy to discuss process when I return.

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Fri, Mar 23, 2012 at 06:29, Robert Newson <rn...@apache.org> wrote:
> In these recent cases all I see is that a few minutes of discussion
> would have saved a lot of noise. We should be collaborating closely at
> the tail end of a release.
>
> In general, though, I thought we already were review before commit,
> which is why patches go to JIRA or we make branches in git. It's just
> me that thinks this?

Sorry to get ruffled just a moment ago. If there's a time for me to be
committing to release branches without review, it's not 5:30am. My
apologies. I appreciate Noah's response about good faith, though. I
contemplated IRC, but decided it would be too involving and then
decided that just e-mailing saying "you all deal with it" or sleeping
felt wrong, too. I suppose I can't hope to be both helpful and
simultaneously not fully engrossed.

Let's have a real discussion about commit policy really soon.

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

In these recent cases all I see is that a few minutes of discussion
would have saved a lot of noise. We should be collaborating closely at
the tail end of a release.

In general, though, I thought we already were review before commit,
which is why patches go to JIRA or we make branches in git. It's just
me that thinks this?

B.

On 23 March 2012 13:27, Noah Slater <ns...@tumbolia.org> wrote:
> Review after commit, by default, is fine. It should be review before commit on a hot release branch, and the active release manager should be consulted in all instances. These changes have wasted a significant amount of my time, and pushed this release back by half a week.
>
> In fairness, this is not written down anywhere, and Randal was acting in good faith, so I do not blame him for these issues. I will be documenting some of this stuff, for clarification and future reference, after the release.
>
> Let's leave it at that, and revisit best practices later.
>
> On 23 Mar 2012, at 13:17, Robert Newson <rn...@apache.org> wrote:
>
>> Finally, the review-after-commit approach bothers me, especially at
>> crunch times like this. Can we get a chance to preview and discuss
>> changes while we're trying to push out a release please?
>>
>> B.
>>
>> On 23 March 2012 13:15, Robert Newson <rn...@apache.org> wrote:
>>> I'm also -1 on your revised solution. We go to the trouble of
>>> carefully logging and formatting these errors and then log them at a
>>> level that approximately no one ever runs at (debug is far too noisy
>>> to use in production, for instance).
>>>
>>> B.
>>>
>>> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>>>> " Is there a good reason why we don't honor
>>>> the create option in the way I expected?"
>>>>
>>>> Is there a good reason you committed a fix to a release branch without
>>>> testing it?
>>>>
>>>> :)
>>>>
>>>> B.
>>>>
>>>> On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
>>>>> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>>>>>> Release is still blocked as a clean startup now logs spurious errors
>>>>>> (1.1.x and 1.2.x);
>>>>>
>>>>> Filipe had asked me to include a log message there after my logging
>>>>> related commits. I've just committed a change that reduces this to
>>>>> debug level.
>>>>>
>>>>> Unfortunately, there doesn't appear to be a way to request that
>>>>> couch_file create the file if it doesn't exist, but just open it if it
>>>>> does. Instead, we require the overwrite option in order not to bail
>>>>> out. Otherwise, couch_replication_manager and couch_auth_cache could
>>>>> just add the create option when opening these system databases rather
>>>>> than detecting the error themselves and issuing couch_db:create after
>>>>> the failed couch_db:open. Is there a good reason why we don't honor
>>>>> the create option in the way I expected? The only reason I see is so
>>>>> that we can return an error to clients that POST/PUT to create a new
>>>>> database, but specifying the exclusive option to file:open actually
>>>>> addresses this.
>>>>>
>>>>> Anyway, the simple fix (to lower the log level) is committed to both branches.
>>>>>
>>>>>>
>>>>>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>>>>>> [error] [<0.87.0>] Error opening file
>>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>>>>>> or directory
>>>>>> [error] [<0.87.0>] Error opening file
>>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>>>>>> such file or directory
>>>>>> [error] [<0.100.0>] Error opening file
>>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>>>>>> file or directory
>>>>>> [error] [<0.100.0>] Error opening file
>>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>>>>>> no such file or directory
>>>>>> Apache CouchDB has started. Time to relax.
>>>>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>>>>>
>>>>>> B.
>>>>>>
>>>>>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>>>>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>>> This is great! Browser tests too, please! Thanks!
>>>>>>>>
>>>>>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>>>>
>>>>>>>>>> Have you added the appropriate entries in NEWS and CHANGES?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have just now. Running make check so I can give you the green light.
>>>>>>>>> Would appreciate if anyone else would do the same.
>>>>>>>
>>>>>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>>>>>> found one tiny issue that remained with my changes and squashed it.
>>>>>>> Green light from me.
>>>>>>>
>>>>>>> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Review after commit, by default, is fine. It should be review before commit on a hot release branch, and the active release manager should be consulted in all instances. These changes have wasted a significant amount of my time, and pushed this release back by half a week.

In fairness, this is not written down anywhere, and Randal was acting in good faith, so I do not blame him for these issues. I will be documenting some of this stuff, for clarification and future reference, after the release.

Let's leave it at that, and revisit best practices later.

On 23 Mar 2012, at 13:17, Robert Newson <rn...@apache.org> wrote:

> Finally, the review-after-commit approach bothers me, especially at
> crunch times like this. Can we get a chance to preview and discuss
> changes while we're trying to push out a release please?
> 
> B.
> 
> On 23 March 2012 13:15, Robert Newson <rn...@apache.org> wrote:
>> I'm also -1 on your revised solution. We go to the trouble of
>> carefully logging and formatting these errors and then log them at a
>> level that approximately no one ever runs at (debug is far too noisy
>> to use in production, for instance).
>> 
>> B.
>> 
>> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>>> " Is there a good reason why we don't honor
>>> the create option in the way I expected?"
>>> 
>>> Is there a good reason you committed a fix to a release branch without
>>> testing it?
>>> 
>>> :)
>>> 
>>> B.
>>> 
>>> On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
>>>> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>>>>> Release is still blocked as a clean startup now logs spurious errors
>>>>> (1.1.x and 1.2.x);
>>>> 
>>>> Filipe had asked me to include a log message there after my logging
>>>> related commits. I've just committed a change that reduces this to
>>>> debug level.
>>>> 
>>>> Unfortunately, there doesn't appear to be a way to request that
>>>> couch_file create the file if it doesn't exist, but just open it if it
>>>> does. Instead, we require the overwrite option in order not to bail
>>>> out. Otherwise, couch_replication_manager and couch_auth_cache could
>>>> just add the create option when opening these system databases rather
>>>> than detecting the error themselves and issuing couch_db:create after
>>>> the failed couch_db:open. Is there a good reason why we don't honor
>>>> the create option in the way I expected? The only reason I see is so
>>>> that we can return an error to clients that POST/PUT to create a new
>>>> database, but specifying the exclusive option to file:open actually
>>>> addresses this.
>>>> 
>>>> Anyway, the simple fix (to lower the log level) is committed to both branches.
>>>> 
>>>>> 
>>>>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>>>>> [error] [<0.87.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>>>>> or directory
>>>>> [error] [<0.87.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>>>>> such file or directory
>>>>> [error] [<0.100.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>>>>> file or directory
>>>>> [error] [<0.100.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>>>>> no such file or directory
>>>>> Apache CouchDB has started. Time to relax.
>>>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>>>> 
>>>>> B.
>>>>> 
>>>>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>>>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>> This is great! Browser tests too, please! Thanks!
>>>>>>> 
>>>>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>>>> 
>>>>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>>> 
>>>>>>>>> Have you added the appropriate entries in NEWS and CHANGES?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I have just now. Running make check so I can give you the green light.
>>>>>>>> Would appreciate if anyone else would do the same.
>>>>>> 
>>>>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>>>>> found one tiny issue that remained with my changes and squashed it.
>>>>>> Green light from me.
>>>>>> 
>>>>>> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Jason Smith <jh...@iriscouch.com>]

Bob, I'm not sure there would be much practical difference in this
case. If we were all committing to 1.2.x-the_last_bugfix then the
activity would simply be happening there. Right?

I would like to have a post-review vs. pre-review discussion, but
perhaps in a different thread?

On Fri, Mar 23, 2012 at 1:17 PM, Robert Newson <rn...@apache.org> wrote:
> Finally, the review-after-commit approach bothers me, especially at
> crunch times like this. Can we get a chance to preview and discuss
> changes while we're trying to push out a release please?
>
> B.
>
> On 23 March 2012 13:15, Robert Newson <rn...@apache.org> wrote:
>> I'm also -1 on your revised solution. We go to the trouble of
>> carefully logging and formatting these errors and then log them at a
>> level that approximately no one ever runs at (debug is far too noisy
>> to use in production, for instance).
>>
>> B.
>>
>> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>>> " Is there a good reason why we don't honor
>>> the create option in the way I expected?"
>>>
>>> Is there a good reason you committed a fix to a release branch without
>>> testing it?
>>>
>>> :)
>>>
>>> B.
>>>
>>> On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
>>>> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>>>>> Release is still blocked as a clean startup now logs spurious errors
>>>>> (1.1.x and 1.2.x);
>>>>
>>>> Filipe had asked me to include a log message there after my logging
>>>> related commits. I've just committed a change that reduces this to
>>>> debug level.
>>>>
>>>> Unfortunately, there doesn't appear to be a way to request that
>>>> couch_file create the file if it doesn't exist, but just open it if it
>>>> does. Instead, we require the overwrite option in order not to bail
>>>> out. Otherwise, couch_replication_manager and couch_auth_cache could
>>>> just add the create option when opening these system databases rather
>>>> than detecting the error themselves and issuing couch_db:create after
>>>> the failed couch_db:open. Is there a good reason why we don't honor
>>>> the create option in the way I expected? The only reason I see is so
>>>> that we can return an error to clients that POST/PUT to create a new
>>>> database, but specifying the exclusive option to file:open actually
>>>> addresses this.
>>>>
>>>> Anyway, the simple fix (to lower the log level) is committed to both branches.
>>>>
>>>>>
>>>>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>>>>> [error] [<0.87.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>>>>> or directory
>>>>> [error] [<0.87.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>>>>> such file or directory
>>>>> [error] [<0.100.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>>>>> file or directory
>>>>> [error] [<0.100.0>] Error opening file
>>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>>>>> no such file or directory
>>>>> Apache CouchDB has started. Time to relax.
>>>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>>>>
>>>>> B.
>>>>>
>>>>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>>>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>> This is great! Browser tests too, please! Thanks!
>>>>>>>
>>>>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>>>>
>>>>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>>>
>>>>>>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>>>>>>> >
>>>>>>>>
>>>>>>>> I have just now. Running make check so I can give you the green light.
>>>>>>>> Would appreciate if anyone else would do the same.
>>>>>>
>>>>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>>>>> found one tiny issue that remained with my changes and squashed it.
>>>>>> Green light from me.
>>>>>>
>>>>>> I'm online for several hours if you need me.



-- 
Iris Couch

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

Finally, the review-after-commit approach bothers me, especially at
crunch times like this. Can we get a chance to preview and discuss
changes while we're trying to push out a release please?

B.

On 23 March 2012 13:15, Robert Newson <rn...@apache.org> wrote:
> I'm also -1 on your revised solution. We go to the trouble of
> carefully logging and formatting these errors and then log them at a
> level that approximately no one ever runs at (debug is far too noisy
> to use in production, for instance).
>
> B.
>
> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>> " Is there a good reason why we don't honor
>> the create option in the way I expected?"
>>
>> Is there a good reason you committed a fix to a release branch without
>> testing it?
>>
>> :)
>>
>> B.
>>
>> On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
>>> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>>>> Release is still blocked as a clean startup now logs spurious errors
>>>> (1.1.x and 1.2.x);
>>>
>>> Filipe had asked me to include a log message there after my logging
>>> related commits. I've just committed a change that reduces this to
>>> debug level.
>>>
>>> Unfortunately, there doesn't appear to be a way to request that
>>> couch_file create the file if it doesn't exist, but just open it if it
>>> does. Instead, we require the overwrite option in order not to bail
>>> out. Otherwise, couch_replication_manager and couch_auth_cache could
>>> just add the create option when opening these system databases rather
>>> than detecting the error themselves and issuing couch_db:create after
>>> the failed couch_db:open. Is there a good reason why we don't honor
>>> the create option in the way I expected? The only reason I see is so
>>> that we can return an error to clients that POST/PUT to create a new
>>> database, but specifying the exclusive option to file:open actually
>>> addresses this.
>>>
>>> Anyway, the simple fix (to lower the log level) is committed to both branches.
>>>
>>>>
>>>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>>>> [error] [<0.87.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>>>> or directory
>>>> [error] [<0.87.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>>>> such file or directory
>>>> [error] [<0.100.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>>>> file or directory
>>>> [error] [<0.100.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>>>> no such file or directory
>>>> Apache CouchDB has started. Time to relax.
>>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>>>
>>>> B.
>>>>
>>>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>> This is great! Browser tests too, please! Thanks!
>>>>>>
>>>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>>>
>>>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>>
>>>>>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>>>>>> >
>>>>>>>
>>>>>>> I have just now. Running make check so I can give you the green light.
>>>>>>> Would appreciate if anyone else would do the same.
>>>>>
>>>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>>>> found one tiny issue that remained with my changes and squashed it.
>>>>> Green light from me.
>>>>>
>>>>> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Jason Smith <jh...@iriscouch.com>]

Can we go back to the bug discussion briefly?

Did the bug described in COUCHDB-1445 ship in version 1.1.1?

If so, I respectfully urge that we pull this whole commit sequence out
of 1.2.x and ship.

If not, sure, carry on.

On Fri, Mar 23, 2012 at 1:15 PM, Robert Newson <rn...@apache.org> wrote:
> I'm also -1 on your revised solution. We go to the trouble of
> carefully logging and formatting these errors and then log them at a
> level that approximately no one ever runs at (debug is far too noisy
> to use in production, for instance).
>
> B.
>
> On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
>> " Is there a good reason why we don't honor
>> the create option in the way I expected?"
>>
>> Is there a good reason you committed a fix to a release branch without
>> testing it?
>>
>> :)
>>
>> B.
>>
>> On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
>>> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>>>> Release is still blocked as a clean startup now logs spurious errors
>>>> (1.1.x and 1.2.x);
>>>
>>> Filipe had asked me to include a log message there after my logging
>>> related commits. I've just committed a change that reduces this to
>>> debug level.
>>>
>>> Unfortunately, there doesn't appear to be a way to request that
>>> couch_file create the file if it doesn't exist, but just open it if it
>>> does. Instead, we require the overwrite option in order not to bail
>>> out. Otherwise, couch_replication_manager and couch_auth_cache could
>>> just add the create option when opening these system databases rather
>>> than detecting the error themselves and issuing couch_db:create after
>>> the failed couch_db:open. Is there a good reason why we don't honor
>>> the create option in the way I expected? The only reason I see is so
>>> that we can return an error to clients that POST/PUT to create a new
>>> database, but specifying the exclusive option to file:open actually
>>> addresses this.
>>>
>>> Anyway, the simple fix (to lower the log level) is committed to both branches.
>>>
>>>>
>>>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>>>> [error] [<0.87.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>>>> or directory
>>>> [error] [<0.87.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>>>> such file or directory
>>>> [error] [<0.100.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>>>> file or directory
>>>> [error] [<0.100.0>] Error opening file
>>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>>>> no such file or directory
>>>> Apache CouchDB has started. Time to relax.
>>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>>>
>>>> B.
>>>>
>>>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>> This is great! Browser tests too, please! Thanks!
>>>>>>
>>>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>>>
>>>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>>
>>>>>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>>>>>> >
>>>>>>>
>>>>>>> I have just now. Running make check so I can give you the green light.
>>>>>>> Would appreciate if anyone else would do the same.
>>>>>
>>>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>>>> found one tiny issue that remained with my changes and squashed it.
>>>>> Green light from me.
>>>>>
>>>>> I'm online for several hours if you need me.



-- 
Iris Couch

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

I'm also -1 on your revised solution. We go to the trouble of
carefully logging and formatting these errors and then log them at a
level that approximately no one ever runs at (debug is far too noisy
to use in production, for instance).

B.

On 23 March 2012 13:14, Robert Newson <rn...@apache.org> wrote:
> " Is there a good reason why we don't honor
> the create option in the way I expected?"
>
> Is there a good reason you committed a fix to a release branch without
> testing it?
>
> :)
>
> B.
>
> On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
>> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>>> Release is still blocked as a clean startup now logs spurious errors
>>> (1.1.x and 1.2.x);
>>
>> Filipe had asked me to include a log message there after my logging
>> related commits. I've just committed a change that reduces this to
>> debug level.
>>
>> Unfortunately, there doesn't appear to be a way to request that
>> couch_file create the file if it doesn't exist, but just open it if it
>> does. Instead, we require the overwrite option in order not to bail
>> out. Otherwise, couch_replication_manager and couch_auth_cache could
>> just add the create option when opening these system databases rather
>> than detecting the error themselves and issuing couch_db:create after
>> the failed couch_db:open. Is there a good reason why we don't honor
>> the create option in the way I expected? The only reason I see is so
>> that we can return an error to clients that POST/PUT to create a new
>> database, but specifying the exclusive option to file:open actually
>> addresses this.
>>
>> Anyway, the simple fix (to lower the log level) is committed to both branches.
>>
>>>
>>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>>> [error] [<0.87.0>] Error opening file
>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>>> or directory
>>> [error] [<0.87.0>] Error opening file
>>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>>> such file or directory
>>> [error] [<0.100.0>] Error opening file
>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>>> file or directory
>>> [error] [<0.100.0>] Error opening file
>>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>>> no such file or directory
>>> Apache CouchDB has started. Time to relax.
>>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>>
>>> B.
>>>
>>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>>> This is great! Browser tests too, please! Thanks!
>>>>>
>>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>>
>>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>>
>>>>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>>>>> >
>>>>>>
>>>>>> I have just now. Running make check so I can give you the green light.
>>>>>> Would appreciate if anyone else would do the same.
>>>>
>>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>>> found one tiny issue that remained with my changes and squashed it.
>>>> Green light from me.
>>>>
>>>> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

" Is there a good reason why we don't honor
the create option in the way I expected?"

Is there a good reason you committed a fix to a release branch without
testing it?

:)

B.

On 23 March 2012 13:12, Randall Leeds <ra...@gmail.com> wrote:
> On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
>> Release is still blocked as a clean startup now logs spurious errors
>> (1.1.x and 1.2.x);
>
> Filipe had asked me to include a log message there after my logging
> related commits. I've just committed a change that reduces this to
> debug level.
>
> Unfortunately, there doesn't appear to be a way to request that
> couch_file create the file if it doesn't exist, but just open it if it
> does. Instead, we require the overwrite option in order not to bail
> out. Otherwise, couch_replication_manager and couch_auth_cache could
> just add the create option when opening these system databases rather
> than detecting the error themselves and issuing couch_db:create after
> the failed couch_db:open. Is there a good reason why we don't honor
> the create option in the way I expected? The only reason I see is so
> that we can return an error to clients that POST/PUT to create a new
> database, but specifying the exclusive option to file:open actually
> addresses this.
>
> Anyway, the simple fix (to lower the log level) is committed to both branches.
>
>>
>> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
>> [error] [<0.87.0>] Error opening file
>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
>> or directory
>> [error] [<0.87.0>] Error opening file
>> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
>> such file or directory
>> [error] [<0.100.0>] Error opening file
>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
>> file or directory
>> [error] [<0.100.0>] Error opening file
>> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
>> no such file or directory
>> Apache CouchDB has started. Time to relax.
>> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>>
>> B.
>>
>> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>>> This is great! Browser tests too, please! Thanks!
>>>>
>>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>>
>>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>>
>>>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>>>> >
>>>>>
>>>>> I have just now. Running make check so I can give you the green light.
>>>>> Would appreciate if anyone else would do the same.
>>>
>>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>>> found one tiny issue that remained with my changes and squashed it.
>>> Green light from me.
>>>
>>> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Fri, Mar 23, 2012 at 03:21, Robert Newson <rn...@apache.org> wrote:
> Release is still blocked as a clean startup now logs spurious errors
> (1.1.x and 1.2.x);

Filipe had asked me to include a log message there after my logging
related commits. I've just committed a change that reduces this to
debug level.

Unfortunately, there doesn't appear to be a way to request that
couch_file create the file if it doesn't exist, but just open it if it
does. Instead, we require the overwrite option in order not to bail
out. Otherwise, couch_replication_manager and couch_auth_cache could
just add the create option when opening these system databases rather
than detecting the error themselves and issuing couch_db:create after
the failed couch_db:open. Is there a good reason why we don't honor
the create option in the way I expected? The only reason I see is so
that we can return an error to clients that POST/PUT to create a new
database, but specifying the exclusive option to file:open actually
addresses this.

Anyway, the simple fix (to lower the log level) is committed to both branches.

>
> Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
> [error] [<0.87.0>] Error opening file
> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
> or directory
> [error] [<0.87.0>] Error opening file
> /Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
> such file or directory
> [error] [<0.100.0>] Error opening file
> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
> file or directory
> [error] [<0.100.0>] Error opening file
> /Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
> no such file or directory
> Apache CouchDB has started. Time to relax.
> [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>
> B.
>
> On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
>> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>>> This is great! Browser tests too, please! Thanks!
>>>
>>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>>
>>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>>
>>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>>> >
>>>>
>>>> I have just now. Running make check so I can give you the green light.
>>>> Would appreciate if anyone else would do the same.
>>
>> Make check and futon tests pass here. Bob Dionne confirms the same. We
>> found one tiny issue that remained with my changes and squashed it.
>> Green light from me.
>>
>> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Robert Newson <rn...@apache.org>]

Release is still blocked as a clean startup now logs spurious errors
(1.1.x and 1.2.x);

Apache CouchDB 1.1.2a3e2280b-git (LogLevel=info) is starting.
[error] [<0.87.0>] Error opening file
/Users/robertnewson/Source/couchdb/tmp/lib/_users.couch: no such file
or directory
[error] [<0.87.0>] Error opening file
/Users/robertnewson/Source/couchdb/tmp/lib/_users.couch.compact: no
such file or directory
[error] [<0.100.0>] Error opening file
/Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch: no such
file or directory
[error] [<0.100.0>] Error opening file
/Users/robertnewson/Source/couchdb/tmp/lib/_replicator.couch.compact:
no such file or directory
Apache CouchDB has started. Time to relax.
[info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/

B.

On 21 March 2012 21:44, Randall Leeds <ra...@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
>> This is great! Browser tests too, please! Thanks!
>>
>> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>>
>>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>>
>>> > Have you added the appropriate entries in NEWS and CHANGES?
>>> >
>>>
>>> I have just now. Running make check so I can give you the green light.
>>> Would appreciate if anyone else would do the same.
>
> Make check and futon tests pass here. Bob Dionne confirms the same. We
> found one tiny issue that remained with my changes and squashed it.
> Green light from me.
>
> I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Wed, Mar 21, 2012 at 13:47, Noah Slater <ns...@tumbolia.org> wrote:
> This is great! Browser tests too, please! Thanks!
>
> On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:
>
>> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>>
>> > Have you added the appropriate entries in NEWS and CHANGES?
>> >
>>
>> I have just now. Running make check so I can give you the green light.
>> Would appreciate if anyone else would do the same.

Make check and futon tests pass here. Bob Dionne confirms the same. We
found one tiny issue that remained with my changes and squashed it.
Green light from me.

I'm online for several hours if you need me.

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

This is great! Browser tests too, please! Thanks!

On Wed, Mar 21, 2012 at 8:42 PM, Randall Leeds <ra...@gmail.com>wrote:

> On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:
>
> > Have you added the appropriate entries in NEWS and CHANGES?
> >
>
> I have just now. Running make check so I can give you the green light.
> Would appreciate if anyone else would do the same.
>
>
> >
> > On Wed, Mar 21, 2012 at 8:08 PM, Randall Leeds <randall.leeds@gmail.com
> > >wrote:
> >
> > > On Mar 21, 2012 11:54 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
> > > >
> > > > Thanks! Do they relate to a ticket? How should I summarise the
> changes?
> > >
> > > They amount to improvement on COUCHDB-966, and could be summarized as
> > "more
> > > descriptive messages for file-related error conditions".
> > >
> >
>

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Wed, Mar 21, 2012 at 13:21, Noah Slater <ns...@tumbolia.org> wrote:

> Have you added the appropriate entries in NEWS and CHANGES?
>

I have just now. Running make check so I can give you the green light.
Would appreciate if anyone else would do the same.


>
> On Wed, Mar 21, 2012 at 8:08 PM, Randall Leeds <randall.leeds@gmail.com
> >wrote:
>
> > On Mar 21, 2012 11:54 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
> > >
> > > Thanks! Do they relate to a ticket? How should I summarise the changes?
> >
> > They amount to improvement on COUCHDB-966, and could be summarized as
> "more
> > descriptive messages for file-related error conditions".
> >
>

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Have you added the appropriate entries in NEWS and CHANGES?

On Wed, Mar 21, 2012 at 8:08 PM, Randall Leeds <ra...@gmail.com>wrote:

> On Mar 21, 2012 11:54 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
> >
> > Thanks! Do they relate to a ticket? How should I summarise the changes?
>
> They amount to improvement on COUCHDB-966, and could be summarized as "more
> descriptive messages for file-related error conditions".
>

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Mar 21, 2012 11:54 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
>
> Thanks! Do they relate to a ticket? How should I summarise the changes?

They amount to improvement on COUCHDB-966, and could be summarized as "more
descriptive messages for file-related error conditions".

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Thanks! Do they relate to a ticket? How should I summarise the changes?

On Wed, Mar 21, 2012 at 6:45 PM, Randall Leeds <ra...@gmail.com>wrote:

> I'll run the tests shortly so I feel confident saying yes.
>
> And I lied before... Logging changes were not all related to that ticket.
> Apologies.
> On Mar 21, 2012 11:32 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
>
> > Thanks.
> >
> > Am I good to attempt the release again tonight?
> >
> > (Please answer carefully, each attempt is an investment of about an hour
> of
> > my time.)
> >
> > On Wed, Mar 21, 2012 at 5:28 PM, Randall Leeds <randall.leeds@gmail.com
> > >wrote:
> >
> > > On Mar 21, 2012 5:41 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
> > > >
> > > > I am looking here:
> > > >
> > > >
> > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.2.x
> > > >
> > > > A lot of stuff by Randal. Is it all for 1445?
> > > >
> > >
> > > Yes.
> > >
> > > > Should I include 1445 in my list of changes since round 2?
> > >
> > > Yes.
> > >
> > > >
> > > > Is there anything else?
> > >
> > > Not that I'm aware of.
> > >
> >
>

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

I'll run the tests shortly so I feel confident saying yes.

And I lied before... Logging changes were not all related to that ticket.
Apologies.
On Mar 21, 2012 11:32 AM, "Noah Slater" <ns...@tumbolia.org> wrote:

> Thanks.
>
> Am I good to attempt the release again tonight?
>
> (Please answer carefully, each attempt is an investment of about an hour of
> my time.)
>
> On Wed, Mar 21, 2012 at 5:28 PM, Randall Leeds <randall.leeds@gmail.com
> >wrote:
>
> > On Mar 21, 2012 5:41 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
> > >
> > > I am looking here:
> > >
> > >
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.2.x
> > >
> > > A lot of stuff by Randal. Is it all for 1445?
> > >
> >
> > Yes.
> >
> > > Should I include 1445 in my list of changes since round 2?
> >
> > Yes.
> >
> > >
> > > Is there anything else?
> >
> > Not that I'm aware of.
> >
>

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Thanks.

Am I good to attempt the release again tonight?

(Please answer carefully, each attempt is an investment of about an hour of
my time.)

On Wed, Mar 21, 2012 at 5:28 PM, Randall Leeds <ra...@gmail.com>wrote:

> On Mar 21, 2012 5:41 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
> >
> > I am looking here:
> >
> >
>
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.2.x
> >
> > A lot of stuff by Randal. Is it all for 1445?
> >
>
> Yes.
>
> > Should I include 1445 in my list of changes since round 2?
>
> Yes.
>
> >
> > Is there anything else?
>
> Not that I'm aware of.
>

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Mar 21, 2012 5:41 AM, "Noah Slater" <ns...@tumbolia.org> wrote:
>
> I am looking here:
>
>
http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.2.x
>
> A lot of stuff by Randal. Is it all for 1445?
>

Yes.

> Should I include 1445 in my list of changes since round 2?

Yes.

>
> Is there anything else?

Not that I'm aware of.

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

I am looking here:

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.2.x

A lot of stuff by Randal. Is it all for 1445?

Should I include 1445 in my list of changes since round 2?

Is there anything else?

(With the exception of the four issues I called out explicitly.)

On Wed, Mar 21, 2012 at 12:01 PM, Paul Davis <pa...@gmail.com>wrote:

> On Wed, Mar 21, 2012 at 6:16 AM, Noah Slater <ns...@tumbolia.org> wrote:
> > I noticed this, along with a few other changes, made to the 1.2.x branch,
> > that do not seem related to the release blockers.
> >
>
> Its related to COUCHDB-1445. Not sure about the other ones.
>
> > Randal, or anyone else, could you explain what they are for?
> >
>
> You'll have to be more specific for me to comment on anything else.
>
> > On Wed, Mar 21, 2012 at 9:17 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >
> >> Yeah, it worked out, thanks. The frustrating problem with incorrect
> >> `receive` patterns is
> >>
> >> On Wed, Mar 21, 2012 at 8:49 AM, Randall Leeds <randall.leeds@gmail.com
> >
> >> wrote:
> >> > On Wed, Mar 21, 2012 at 01:34, Randall Leeds <randall.leeds@gmail.com
> >> >wrote:
> >> >
> >> >> Thanks for cleaning up after me. Sloppy, Randall. Bad, Randall.
> >> >>
> >> >
> >> > Well, I was mostly right...
> >> >
> >> >
> >> >> >>> In particular, the error is with the change to couch_log.erl.
> >> >>> >>
> >> >>> >> Whoops. I meant couch_file.erl.
> >> >>> >>
> >> >>> >> Randall, please see the attached diff, or see
> >> >>> >> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
> >> >>> >>
> >> >>> >> The pattern {Ref, Pid, {error, Reason}} does not match because
> the
> >> >>> >> message is {Ref, Pid, Reason}
> >> >>>
> >> >>
> >> >>
> >> > Only in one case, where we detect that the file exists.
> >> > I've changed it to return {error, eexist} in this case, which matches
> the
> >> > errors that come back from the file module in all other places and
> will
> >> > format the correct message.
> >> >
> >> > Fixed on 1.1.x and 1.2.x.
> >>
> >>
> >>
> >> --
> >> Iris Couch
> >>
>

Re: Problems blocking 1.2.0

[Paul Davis <pa...@gmail.com>]

On Wed, Mar 21, 2012 at 6:16 AM, Noah Slater <ns...@tumbolia.org> wrote:
> I noticed this, along with a few other changes, made to the 1.2.x branch,
> that do not seem related to the release blockers.
>

Its related to COUCHDB-1445. Not sure about the other ones.

> Randal, or anyone else, could you explain what they are for?
>

You'll have to be more specific for me to comment on anything else.

> On Wed, Mar 21, 2012 at 9:17 AM, Jason Smith <jh...@iriscouch.com> wrote:
>
>> Yeah, it worked out, thanks. The frustrating problem with incorrect
>> `receive` patterns is
>>
>> On Wed, Mar 21, 2012 at 8:49 AM, Randall Leeds <ra...@gmail.com>
>> wrote:
>> > On Wed, Mar 21, 2012 at 01:34, Randall Leeds <randall.leeds@gmail.com
>> >wrote:
>> >
>> >> Thanks for cleaning up after me. Sloppy, Randall. Bad, Randall.
>> >>
>> >
>> > Well, I was mostly right...
>> >
>> >
>> >> >>> In particular, the error is with the change to couch_log.erl.
>> >>> >>
>> >>> >> Whoops. I meant couch_file.erl.
>> >>> >>
>> >>> >> Randall, please see the attached diff, or see
>> >>> >> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
>> >>> >>
>> >>> >> The pattern {Ref, Pid, {error, Reason}} does not match because the
>> >>> >> message is {Ref, Pid, Reason}
>> >>>
>> >>
>> >>
>> > Only in one case, where we detect that the file exists.
>> > I've changed it to return {error, eexist} in this case, which matches the
>> > errors that come back from the file module in all other places and will
>> > format the correct message.
>> >
>> > Fixed on 1.1.x and 1.2.x.
>>
>>
>>
>> --
>> Iris Couch
>>

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

I noticed this, along with a few other changes, made to the 1.2.x branch,
that do not seem related to the release blockers.

Randal, or anyone else, could you explain what they are for?

On Wed, Mar 21, 2012 at 9:17 AM, Jason Smith <jh...@iriscouch.com> wrote:

> Yeah, it worked out, thanks. The frustrating problem with incorrect
> `receive` patterns is
>
> On Wed, Mar 21, 2012 at 8:49 AM, Randall Leeds <ra...@gmail.com>
> wrote:
> > On Wed, Mar 21, 2012 at 01:34, Randall Leeds <randall.leeds@gmail.com
> >wrote:
> >
> >> Thanks for cleaning up after me. Sloppy, Randall. Bad, Randall.
> >>
> >
> > Well, I was mostly right...
> >
> >
> >> >>> In particular, the error is with the change to couch_log.erl.
> >>> >>
> >>> >> Whoops. I meant couch_file.erl.
> >>> >>
> >>> >> Randall, please see the attached diff, or see
> >>> >> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
> >>> >>
> >>> >> The pattern {Ref, Pid, {error, Reason}} does not match because the
> >>> >> message is {Ref, Pid, Reason}
> >>>
> >>
> >>
> > Only in one case, where we detect that the file exists.
> > I've changed it to return {error, eexist} in this case, which matches the
> > errors that come back from the file module in all other places and will
> > format the correct message.
> >
> > Fixed on 1.1.x and 1.2.x.
>
>
>
> --
> Iris Couch
>

Re: Problems blocking 1.2.0

[Jason Smith <jh...@iriscouch.com>]

Yeah, it worked out, thanks. The frustrating problem with incorrect
`receive` patterns is

On Wed, Mar 21, 2012 at 8:49 AM, Randall Leeds <ra...@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 01:34, Randall Leeds <ra...@gmail.com>wrote:
>
>> Thanks for cleaning up after me. Sloppy, Randall. Bad, Randall.
>>
>
> Well, I was mostly right...
>
>
>> >>> In particular, the error is with the change to couch_log.erl.
>>> >>
>>> >> Whoops. I meant couch_file.erl.
>>> >>
>>> >> Randall, please see the attached diff, or see
>>> >> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
>>> >>
>>> >> The pattern {Ref, Pid, {error, Reason}} does not match because the
>>> >> message is {Ref, Pid, Reason}
>>>
>>
>>
> Only in one case, where we detect that the file exists.
> I've changed it to return {error, eexist} in this case, which matches the
> errors that come back from the file module in all other places and will
> format the correct message.
>
> Fixed on 1.1.x and 1.2.x.



-- 
Iris Couch

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

On Wed, Mar 21, 2012 at 01:34, Randall Leeds <ra...@gmail.com>wrote:

> Thanks for cleaning up after me. Sloppy, Randall. Bad, Randall.
>

Well, I was mostly right...


> >>> In particular, the error is with the change to couch_log.erl.
>> >>
>> >> Whoops. I meant couch_file.erl.
>> >>
>> >> Randall, please see the attached diff, or see
>> >> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
>> >>
>> >> The pattern {Ref, Pid, {error, Reason}} does not match because the
>> >> message is {Ref, Pid, Reason}
>>
>
>
Only in one case, where we detect that the file exists.
I've changed it to return {error, eexist} in this case, which matches the
errors that come back from the file module in all other places and will
format the correct message.

Fixed on 1.1.x and 1.2.x.

Re: Problems blocking 1.2.0

[Randall Leeds <ra...@gmail.com>]

Thanks for cleaning up after me. Sloppy, Randall. Bad, Randall.
On Mar 20, 2012 9:32 PM, "Jason Smith" <jh...@iriscouch.com> wrote:

> Done.
>
> On Wed, Mar 21, 2012 at 4:26 AM, Paul Davis <pa...@gmail.com>
> wrote:
> > Looks good enough to me. Something something forgiveness something
> permission.
> >
> > On Tue, Mar 20, 2012 at 10:40 PM, Jason Smith <jh...@apache.org> wrote:
> >> On Wed, Mar 21, 2012 at 9:54 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >>> On Wed, Mar 21, 2012 at 9:49 AM, Jason Smith <jh...@iriscouch.com>
> wrote:
> >>>> The regression began at commit ede9482f.
> >>>>
> >>>>
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb
> >>>
> >>> In particular, the error is with the change to couch_log.erl.
> >>
> >> Whoops. I meant couch_file.erl.
> >>
> >> Randall, please see the attached diff, or see
> >> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
> >>
> >> The pattern {Ref, Pid, {error, Reason}} does not match because the
> >> message is {Ref, Pid, Reason}
> >>
> >> I am unfamiliar with this code but I get the test suite passing with
> >> the change pushed to 1.2.x-couch_file. If it looks okay to someone
> >> more familiar with the issue, would you please merge it with 1.2.x.
> >> Thanks!
>
>
>
> --
> Iris Couch
>

Re: Problems blocking 1.2.0

[Jason Smith <jh...@iriscouch.com>]

Done.

On Wed, Mar 21, 2012 at 4:26 AM, Paul Davis <pa...@gmail.com> wrote:
> Looks good enough to me. Something something forgiveness something permission.
>
> On Tue, Mar 20, 2012 at 10:40 PM, Jason Smith <jh...@apache.org> wrote:
>> On Wed, Mar 21, 2012 at 9:54 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>> On Wed, Mar 21, 2012 at 9:49 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>>> The regression began at commit ede9482f.
>>>>
>>>> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb
>>>
>>> In particular, the error is with the change to couch_log.erl.
>>
>> Whoops. I meant couch_file.erl.
>>
>> Randall, please see the attached diff, or see
>> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
>>
>> The pattern {Ref, Pid, {error, Reason}} does not match because the
>> message is {Ref, Pid, Reason}
>>
>> I am unfamiliar with this code but I get the test suite passing with
>> the change pushed to 1.2.x-couch_file. If it looks okay to someone
>> more familiar with the issue, would you please merge it with 1.2.x.
>> Thanks!



-- 
Iris Couch

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Nothing wrong with being bold, Paul. :) But breaking tests in a hot release
branch is a little frustrating. ;)

On Wed, Mar 21, 2012 at 4:26 AM, Paul Davis <pa...@gmail.com>wrote:

> Looks good enough to me. Something something forgiveness something
> permission.
>
> On Tue, Mar 20, 2012 at 10:40 PM, Jason Smith <jh...@apache.org> wrote:
> > On Wed, Mar 21, 2012 at 9:54 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >> On Wed, Mar 21, 2012 at 9:49 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >>> The regression began at commit ede9482f.
> >>>
> >>>
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb
> >>
> >> In particular, the error is with the change to couch_log.erl.
> >
> > Whoops. I meant couch_file.erl.
> >
> > Randall, please see the attached diff, or see
> > http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
> >
> > The pattern {Ref, Pid, {error, Reason}} does not match because the
> > message is {Ref, Pid, Reason}
> >
> > I am unfamiliar with this code but I get the test suite passing with
> > the change pushed to 1.2.x-couch_file. If it looks okay to someone
> > more familiar with the issue, would you please merge it with 1.2.x.
> > Thanks!
>

Re: Problems blocking 1.2.0

[Paul Davis <pa...@gmail.com>]

Looks good enough to me. Something something forgiveness something permission.

On Tue, Mar 20, 2012 at 10:40 PM, Jason Smith <jh...@apache.org> wrote:
> On Wed, Mar 21, 2012 at 9:54 AM, Jason Smith <jh...@iriscouch.com> wrote:
>> On Wed, Mar 21, 2012 at 9:49 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>> The regression began at commit ede9482f.
>>>
>>> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb
>>
>> In particular, the error is with the change to couch_log.erl.
>
> Whoops. I meant couch_file.erl.
>
> Randall, please see the attached diff, or see
> http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc
>
> The pattern {Ref, Pid, {error, Reason}} does not match because the
> message is {Ref, Pid, Reason}
>
> I am unfamiliar with this code but I get the test suite passing with
> the change pushed to 1.2.x-couch_file. If it looks okay to someone
> more familiar with the issue, would you please merge it with 1.2.x.
> Thanks!

Re: Problems blocking 1.2.0

[Jason Smith <jh...@apache.org>]

On Wed, Mar 21, 2012 at 9:54 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Wed, Mar 21, 2012 at 9:49 AM, Jason Smith <jh...@iriscouch.com> wrote:
>> The regression began at commit ede9482f.
>>
>> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb
>
> In particular, the error is with the change to couch_log.erl.

Whoops. I meant couch_file.erl.

Randall, please see the attached diff, or see
http://friendpaste.com/2Hwjn9uj1oRM8pyRqAdbxc

The pattern {Ref, Pid, {error, Reason}} does not match because the
message is {Ref, Pid, Reason}

I am unfamiliar with this code but I get the test suite passing with
the change pushed to 1.2.x-couch_file. If it looks okay to someone
more familiar with the issue, would you please merge it with 1.2.x.
Thanks!

Re: Problems blocking 1.2.0

[Jason Smith <jh...@iriscouch.com>]

On Wed, Mar 21, 2012 at 9:49 AM, Jason Smith <jh...@iriscouch.com> wrote:
> The regression began at commit ede9482f.
>
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb

In particular, the error is with the change to couch_log.erl.
-- 
Iris Couch

Re: Problems blocking 1.2.0

[Jason Smith <jh...@iriscouch.com>]

The regression began at commit ede9482f.

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ede9482fc3c9e629572ab1376d88f4499c4c8beb

On Wed, Mar 21, 2012 at 8:51 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Full log, with debug turned on:
>
> http://dpaste.org/782RR/
>
> On Wed, Mar 21, 2012 at 1:18 AM, Noah Slater <ns...@tumbolia.org> wrote:
>
>> Hello,
>>
>> There's been a regression in the browser test suite.
>>
>> Building from the 1.2.x branch, the first test, basics, hangs for me.
>>
>> The end of the logs are:
>>
>> [info] [<0.1509.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>> [info] [<0.1603.0>] 127.0.0.1 - - GET / 200
>> [info] [<0.1603.0>] 127.0.0.1 - - GET
>> /test_suite_db/0?rev=3-cac36b6fd7e2c7347b3147626c8cfdaf 200
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db 201
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db 201
>> [info] [<0.1603.0>] 127.0.0.1 - - GET /test_suite_db/oppossum 200
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/newdoc 201
>> [info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_db/doc-does-not-exist
>> 404
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/goldfish 500
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/zebrafish 500
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/mudfish 500
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/tastyfish 500
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/bar 400
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_bulk_docs 400
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_all_docs 400
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_all_docs 400
>> [info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_db/?rev=foobarbaz 400
>> [info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_foobar/ 200
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_foobar 201
>> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_foobar/doc1 201
>> [info] [<0.1603.0>] 127.0.0.1 - - POST
>> /test_suite_foobar/_ensure_full_commit 201
>> [info] [<0.1603.0>] 127.0.0.1 - - GET /test_suite_foobar/ 200
>> [info] [<0.1603.0>] 127.0.0.1 - - POST /_restart 200
>> Apache CouchDB 1.2.0 (LogLevel=info) is starting.
>> Apache CouchDB has started. Time to relax.
>> [info] [<0.1673.0>] Apache CouchDB has started on http://127.0.0.1:5984/
>> [info] [<0.1767.0>] 127.0.0.1 - - GET / 200
>>
>> This happens consistently. (Though the log looks different)
>>
>> Firefox 11.0, private browsing turned on and off, OS X 10.7.3, 11" MBA.
>>
>> Thanks,
>>
>> N
>>
>>



-- 
Iris Couch

Re: Problems blocking 1.2.0

[Noah Slater <ns...@tumbolia.org>]

Full log, with debug turned on:

http://dpaste.org/782RR/

On Wed, Mar 21, 2012 at 1:18 AM, Noah Slater <ns...@tumbolia.org> wrote:

> Hello,
>
> There's been a regression in the browser test suite.
>
> Building from the 1.2.x branch, the first test, basics, hangs for me.
>
> The end of the logs are:
>
> [info] [<0.1509.0>] Apache CouchDB has started on http://127.0.0.1:5984/
> [info] [<0.1603.0>] 127.0.0.1 - - GET / 200
> [info] [<0.1603.0>] 127.0.0.1 - - GET
> /test_suite_db/0?rev=3-cac36b6fd7e2c7347b3147626c8cfdaf 200
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db 201
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db 201
> [info] [<0.1603.0>] 127.0.0.1 - - GET /test_suite_db/oppossum 200
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/newdoc 201
> [info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_db/doc-does-not-exist
> 404
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/goldfish 500
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/zebrafish 500
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/mudfish 500
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/tastyfish 500
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/ 500
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_db/bar 400
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_bulk_docs 400
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_all_docs 400
> [info] [<0.1603.0>] 127.0.0.1 - - POST /test_suite_db/_all_docs 400
> [info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_db/?rev=foobarbaz 400
> [info] [<0.1603.0>] 127.0.0.1 - - DELETE /test_suite_foobar/ 200
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_foobar 201
> [info] [<0.1603.0>] 127.0.0.1 - - PUT /test_suite_foobar/doc1 201
> [info] [<0.1603.0>] 127.0.0.1 - - POST
> /test_suite_foobar/_ensure_full_commit 201
> [info] [<0.1603.0>] 127.0.0.1 - - GET /test_suite_foobar/ 200
> [info] [<0.1603.0>] 127.0.0.1 - - POST /_restart 200
> Apache CouchDB 1.2.0 (LogLevel=info) is starting.
> Apache CouchDB has started. Time to relax.
> [info] [<0.1673.0>] Apache CouchDB has started on http://127.0.0.1:5984/
> [info] [<0.1767.0>] 127.0.0.1 - - GET / 200
>
> This happens consistently. (Though the log looks different)
>
> Firefox 11.0, private browsing turned on and off, OS X 10.7.3, 11" MBA.
>
> Thanks,
>
> N
>
>