Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates
 209.85.210.180 as permitted sender)
MIME-Version: 1.0
Sender: fdmanana@gmail.com
In-Reply-To: 
 <CAL3q7H6xktrCA6Q2tJVUenYTPSGKMz1PoMfGWDOmu5vKA2zK8w@mail.gmail.com>
References: 
 <CABvT1DFXDEZDArbgH0-kZ=U_BMbLETQhORTexbe5pvE3fHh1WQ@mail.gmail.com>
	<CAJ_m3YBOmzXxSFbmfN0urW3=9KsKr1BFmKFL03D537b6v23-mA@mail.gmail.com>
	<CABvT1DHsk=qLWA1TgSAvGZySToMorZb6T2LnqLgseq0u3V7Sbw@mail.gmail.com>
	<CAJ_m3YCwGtF5E0iw0z2OXPurDVEEv76q0v7X2=fkzmtAnS2qzg@mail.gmail.com>
	<CABvT1DGparj-KhOANPbeV4YVy2pv897_XezFYaeqxHDUR5771w@mail.gmail.com>
	<C0C8EAC9-3AFB-4474-8834-1DD45F676777@apache.org>
	<CABvT1DGJVs1gouodXH0KFpEiaWOx0VXRRcMshH9e+GwTMtJmPQ@mail.gmail.com>
	<CABvT1DHENfcVrRrif8Kfa1S7LydFWQ07123gLQ0wwq-HhYo9Tw@mail.gmail.com>
	<CAL3q7H6JS7OONsOmu-m2Ang2gSSR3RZmE44_CmFDGPYv+JAKpA@mail.gmail.com>
	<CABvT1DGakr+3uvWRHTCc69uVhvaDhaUVucVjTEHbv3G+ahuBgg@mail.gmail.com>
	<CAL3q7H6xktrCA6Q2tJVUenYTPSGKMz1PoMfGWDOmu5vKA2zK8w@mail.gmail.com>
Date: Fri, 7 Oct 2011 18:42:06 +0100
Message-ID: 
 <CAL3q7H4GAiok-g=+8B7fGcKcwWvrD-Y2jkzAjjXxL+aKjrhtOQ@mail.gmail.com>
Subject: Re: CouchDB 1.1.1
From: Filipe David Manana <fdmanana@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Regarding the erlang-oauth and R15 compatibility,

The compilation warnings only happen in the 1.1.x because
src/erlang-oauth/Makefile.am is compiling oauth_rsa_sha1.erl while
trunk and 1.2.x are not.

Our OAuth handler is not supporting rsa-sha1 signatures, so it can be
safely ignored. I think the right thing would be to exclude that file
from the build list.

It was added in the following 1.1.x commit:

https://github.com/apache/couchdb/commit/ea57780780730eb5f2d98f30697e6a8c2b=
3cf7f7

That said, upgrading to the same erlang-oauth we have in trunk/1.2.x won't =
help.

On Thu, Oct 6, 2011 at 7:10 PM, Filipe David Manana <fdmanana@apache.org> w=
rote:
> On Thu, Oct 6, 2011 at 6:59 PM, Robert Newson <rnewson@apache.org> wrote:
>> does the newer erlang-oauth break anything?
>
> Not that I know of.
>
>>
>> On 6 October 2011 18:52, Filipe David Manana <fdmanana@apache.org> wrote=
:
>>> On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson <rnewson@apache.org> wrot=
e:
>>>> If there are no objections, I'm going to build the first 1.1.1
>>>> candidate in the morning and start a new thread for the release.
>>>
>>> As pointed out in 2 other related threads, we have some compilation
>>> warnings about functions that will no longer exist in OTP R15 (to be
>>> released by the end of this year):
>>>
>>> /opt/r14b03/bin/erlc +debug_info oauth_http.erl
>>> ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be
>>> removed in R15B; use httpc:request/4
>>> /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl
>>> /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl
>>> ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated
>>> (will be removed in R15A); use file:read_file/1 and
>>> public_key:pem_decode/1
>>> ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is
>>> deprecated and will be removed in R15A; use
>>> public_key:pem_entry_decode/1
>>> ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated
>>> (will be removed in R15A); use file:read_file/1 and
>>> public_key:pem_decode/1
>>> /opt/r14b03/bin/erlc +debug_info oauth_unix.erl
>>>
>>> The ones regarding public_key concern me, as it will break the OAuth
>>> authentication handler.
>>> I see 2 solutions:
>>>
>>> 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x
>>> (doesn't produce these warnings)
>>>
>>> 2) modify the erlang-oauth in 1.1.x and use try catches where the
>>> catch would call the equivalent versions in R14/R15 (these new
>>> functions don't exist in R13B03 for example)
>>>
>>> Naturally, I would prefer 1)
>>>
>>> The warnings about http:request can be ignored I think, as in Couch we
>>> don't use any codepath that will execute the deprecated function
>>>
>>>>
>>>> B.
>>>>
>>>> On 6 October 2011 12:05, Robert Newson <rnewson@apache.org> wrote:
>>>>> Thanks all, I've pushed the change to 1.1.x. make check and futon all
>>>>> pass; review would still be nice. :) I simply reverted the two
>>>>> commits.
>>>>>
>>>>> B.
>>>>>
>>>>> On 6 October 2011 12:02, Jan Lehnardt <jan@apache.org> wrote:
>>>>>>
>>>>>> On Oct 6, 2011, at 10:30 , Robert Newson wrote:
>>>>>>
>>>>>>> There is no build of 1.1.1 on Ubuntu 11.x that will work as well as
>>>>>>> 1.1.0, so I think it's correct that it cannot build under those
>>>>>>> conditions.
>>>>>>>
>>>>>>> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, and
>>>>>>> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING
>>>>>>> CHANGES").
>>>>>>>
>>>>>>> I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Cheers
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> B.
>>>>>>>
>>>>>>> On 6 October 2011 09:25, Paul Davis <paul.joseph.davis@gmail.com> w=
rote:
>>>>>>>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson <rnewson@apache.org>=
 wrote:
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> Paul Davis has researched the issue and it seems intractable.
>>>>>>>>>
>>>>>>>>> I would like to remove 1.8.5 support from 1.1.1. It was not prese=
nt in
>>>>>>>>> 1.1.0 so will not be (officially) missed.
>>>>>>>>>
>>>>>>>>> The place for a breaking change of this magnitude is 1.2, not a m=
inor
>>>>>>>>> bug fix release.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>> B.
>>>>>>>>>
>>>>>>>>
>>>>>>>> +1 on removing the paren hack for sure.
>>>>>>>>
>>>>>>>> Not sure about removing 1.8.5 support completely. On the one hand,=
 it
>>>>>>>> would prevent breakage because people couldn't link against the
>>>>>>>> breaking SM. On the other hand, it prevents people from linking
>>>>>>>> against 1.8.5 which means it won't build on Ubuntu 11.x.
>>>>>>>>
>>>>>>>> Unless someone comes up with a magic option I'd say put it to an
>>>>>>>> informal vote so that I can blame someone else.
>>>>>>>>
>>>>>>>>> On 5 October 2011 18:25, Paul Davis <paul.joseph.davis@gmail.com>=
 wrote:
>>>>>>>>>> Yes, its release blocking.
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson <rnewson@apache.or=
g> wrote:
>>>>>>>>>>> All,
>>>>>>>>>>>
>>>>>>>>>>> I went through JIRA and updated CHANGES and NEWS on origin/1.1.=
x to
>>>>>>>>>>> include everything that was missing (Sidenote: Can we all keep =
this
>>>>>>>>>>> file up to date when commit bugfixes or add features?). I'd app=
reciate
>>>>>>>>>>> everyone giving it a look over before I start to build the rele=
ase
>>>>>>>>>>> artifact.
>>>>>>>>>>>
>>>>>>>>>>> I believe there's an outstanding issue (not present in JIRA) ar=
ound
>>>>>>>>>>> javascript function evaluation? Can someone confirm that it's r=
elease
>>>>>>>>>>> blocking?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> B.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Filipe David Manana,
>>>
>>> "Reasonable men adapt themselves to the world.
>>> =C2=A0Unreasonable men adapt the world to themselves.
>>> =C2=A0That's why all progress depends on unreasonable men."
>>>
>>
>
>
>
> --
> Filipe David Manana,
>
> "Reasonable men adapt themselves to the world.
> =C2=A0Unreasonable men adapt the world to themselves.
> =C2=A0That's why all progress depends on unreasonable men."
>


--=20
Filipe David Manana,

"Reasonable men adapt themselves to the world.
=C2=A0Unreasonable men adapt the world to themselves.
=C2=A0That's why all progress depends on unreasonable men."