You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Rafael Schloming <rh...@alum.mit.edu> on 2014/09/18 16:55:25 UTC

0.8 release prep

Hi Everyone,

I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
order to triage any remaining issues. If there are any particular issues
that you feel strongly should be included in 0.8, please follow up on this
thread and bring them to my attention.

--Rafael

Re: 0.8 release prep

Posted by Ken Giusti <kg...@redhat.com>.

----- Original Message -----
> From: "Cliff Jansen" <cl...@gmail.com>
> To: "proton" <pr...@qpid.apache.org>
> Sent: Thursday, September 18, 2014 12:04:25 PM
> Subject: Re: 0.8 release prep
> 
> I would like someone with better Python/SWIG expertise to take a look
> at PROTON-687, at least to confirm if the python swig wrapper for
> pn_delivery_set_context (and other similar "borrowed" references) are
> the culprits, or the victims of a bug elsewhere.
> 

I can repro this on linux, simply by running the python tests under valgrind.

I've updated the bug, will take a look.

-K


> I would like to update PROTON-581 (Schannel ssl for windows) for
> changes in the SSL internal api and get it checked in.
> 
> I would also like to take a closer look at PROTON-660 (openssl on
> Windows) or have someone else review it for rc1.
> 
> On Thu, Sep 18, 2014 at 8:32 AM, Clebert Suconic <cs...@redhat.com> wrote:
> > I have a commit that I would like to send towards a contrib component:
> >
> > https://github.com/clebertsuconic/qpid-proton/commit/ab423a90f6b1e6d06c84615c5724497a3f9e8533
> >
> >
> >
> > The current code is always encoding it as Bytes, and I need the ProtonJ as
> > an output on the case of the JMS component.
> >
> >
> >
> > On Sep 18, 2014, at 11:15 AM, Miguel da Rocha Correia Lima
> > <mc...@landix.com.br> wrote:
> >
> >> Hi Rafael,
> >>
> >>        The PROTON-661 was useful for us. We are working with this patch
> >>        without any error.
> >>        We supose that it can be useful for others.
> >>
> >> Miguel da Rocha Correia Lima
> >> miguel at landix dot com dot br
> >>
> >> Em 18/09/2014 11:55, Rafael Schloming escreveu:
> >>> Hi Everyone,
> >>>
> >>> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly
> >>> in
> >>> order to triage any remaining issues. If there are any particular issues
> >>> that you feel strongly should be included in 0.8, please follow up on
> >>> this
> >>> thread and bring them to my attention.
> >>>
> >>> --Rafael
> >>>
> >>
> >
> 

-- 
-K

Re: 0.8 release prep

Posted by Cliff Jansen <cl...@gmail.com>.
I would like someone with better Python/SWIG expertise to take a look
at PROTON-687, at least to confirm if the python swig wrapper for
pn_delivery_set_context (and other similar "borrowed" references) are
the culprits, or the victims of a bug elsewhere.

I would like to update PROTON-581 (Schannel ssl for windows) for
changes in the SSL internal api and get it checked in.

I would also like to take a closer look at PROTON-660 (openssl on
Windows) or have someone else review it for rc1.

On Thu, Sep 18, 2014 at 8:32 AM, Clebert Suconic <cs...@redhat.com> wrote:
> I have a commit that I would like to send towards a contrib component:
>
> https://github.com/clebertsuconic/qpid-proton/commit/ab423a90f6b1e6d06c84615c5724497a3f9e8533
>
>
>
> The current code is always encoding it as Bytes, and I need the ProtonJ as an output on the case of the JMS component.
>
>
>
> On Sep 18, 2014, at 11:15 AM, Miguel da Rocha Correia Lima <mc...@landix.com.br> wrote:
>
>> Hi Rafael,
>>
>>        The PROTON-661 was useful for us. We are working with this patch without any error.
>>        We supose that it can be useful for others.
>>
>> Miguel da Rocha Correia Lima
>> miguel at landix dot com dot br
>>
>> Em 18/09/2014 11:55, Rafael Schloming escreveu:
>>> Hi Everyone,
>>>
>>> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
>>> order to triage any remaining issues. If there are any particular issues
>>> that you feel strongly should be included in 0.8, please follow up on this
>>> thread and bring them to my attention.
>>>
>>> --Rafael
>>>
>>
>

Re: 0.8 release prep

Posted by Clebert Suconic <cs...@redhat.com>.
I have a commit that I would like to send towards a contrib component:

https://github.com/clebertsuconic/qpid-proton/commit/ab423a90f6b1e6d06c84615c5724497a3f9e8533



The current code is always encoding it as Bytes, and I need the ProtonJ as an output on the case of the JMS component.



On Sep 18, 2014, at 11:15 AM, Miguel da Rocha Correia Lima <mc...@landix.com.br> wrote:

> Hi Rafael,
> 
>        The PROTON-661 was useful for us. We are working with this patch without any error.
>        We supose that it can be useful for others.
> 
> Miguel da Rocha Correia Lima
> miguel at landix dot com dot br
> 
> Em 18/09/2014 11:55, Rafael Schloming escreveu:
>> Hi Everyone,
>> 
>> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
>> order to triage any remaining issues. If there are any particular issues
>> that you feel strongly should be included in 0.8, please follow up on this
>> thread and bring them to my attention.
>> 
>> --Rafael
>> 
> 


Re: 0.8 release prep

Posted by Rafael Schloming <rh...@alum.mit.edu>.
I'll take a look at the patch if you can resubmit it as a file. The patch
in the comment has lost formatting.

On Thu, Sep 18, 2014 at 11:15 AM, Miguel da Rocha Correia Lima <
mcorreialima@landix.com.br> wrote:

> Hi Rafael,
>
>         The PROTON-661 was useful for us. We are working with this patch
> without any error.
>         We supose that it can be useful for others.
>
> Miguel da Rocha Correia Lima
> miguel at landix dot com dot br
>
> Em 18/09/2014 11:55, Rafael Schloming escreveu:
>
>  Hi Everyone,
>>
>> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
>> order to triage any remaining issues. If there are any particular issues
>> that you feel strongly should be included in 0.8, please follow up on this
>> thread and bring them to my attention.
>>
>> --Rafael
>>
>>
>

Re: 0.8 release prep

Posted by Miguel da Rocha Correia Lima <mc...@landix.com.br>.
Hi Rafael,

         The PROTON-661 was useful for us. We are working with this 
patch without any error.
         We supose that it can be useful for others.

Miguel da Rocha Correia Lima
miguel at landix dot com dot br

Em 18/09/2014 11:55, Rafael Schloming escreveu:
> Hi Everyone,
>
> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
> order to triage any remaining issues. If there are any particular issues
> that you feel strongly should be included in 0.8, please follow up on this
> thread and bring them to my attention.
>
> --Rafael
>


Re: 0.8 release prep

Posted by Robbie Gemmell <ro...@gmail.com>.
This is definitely something that will need to get done eventually, but it
isn't currently being worked on to my knowledge and is unlikely to be in
0.8 as a result. Patches are welcome though.

Robbie

On 18 September 2014 17:15, Fugitt, Jesse <jf...@informatica.com> wrote:

> The missing functionality for idle timeout in Proton-J (JIRA PROTON-111)
> which exists in the C API would be nice at some point so it can be
> leveraged by future releases of ActiveMQ and other projects where keep
> alive behavior is needed by proton/AMQP clients.
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Rafael Schloming [mailto:rhs@alum.mit.edu]
> Sent: Thursday, September 18, 2014 9:55 AM
> To: proton@qpid.apache.org
> Subject: 0.8 release prep
>
> Hi Everyone,
>
> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
> order to triage any remaining issues. If there are any particular issues
> that you feel strongly should be included in 0.8, please follow up on this
> thread and bring them to my attention.
>
> --Rafael
>

RE: 0.8 release prep

Posted by "Fugitt, Jesse" <jf...@informatica.com>.
The missing functionality for idle timeout in Proton-J (JIRA PROTON-111) which exists in the C API would be nice at some point so it can be leveraged by future releases of ActiveMQ and other projects where keep alive behavior is needed by proton/AMQP clients.

Thanks,
Jesse

-----Original Message-----
From: Rafael Schloming [mailto:rhs@alum.mit.edu] 
Sent: Thursday, September 18, 2014 9:55 AM
To: proton@qpid.apache.org
Subject: 0.8 release prep

Hi Everyone,

I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in order to triage any remaining issues. If there are any particular issues that you feel strongly should be included in 0.8, please follow up on this thread and bring them to my attention.

--Rafael

Re: 0.8 release prep

Posted by Clebert Suconic <cs...@redhat.com>.
Can we get this one in:

https://github.com/clebertsuconic/qpid-proton/tree/PROTON-694


The current version always gets me a Bytearray through EncodedMessage while I just need the ProtonJMessage for a later encoding when dealing with JMS Conversions.



I have a patch linked on the issue.


On Sep 21, 2014, at 5:43 PM, Bozo Dragojevic <bo...@digiverse.si> wrote:

> On 18. 09. 14 16:55, Rafael Schloming wrote:
>> Hi Everyone,
>> 
>> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
>> order to triage any remaining issues. If there are any particular issues
>> that you feel strongly should be included in 0.8, please follow up on this
>> thread and bring them to my attention.
>> 
>> --Rafael
>> 
> I'd like to get these two of mine in
> 
> PROTON-660: Fix openssl.c build on windows
> PROTON-691: allow proton to be built with add_subdirectory
> 
> Plus the other half of the Windows IOCP work by Cliff
> 
> PROTON-684: Restrict IOCP enlistment to pn_selector_t usage scenarios in
> Windows
> 
> Bozzo


Re: 0.8 release prep

Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2014-09-23 at 09:50 +0200, Bozo Dragojevic wrote:
> On 22. 09. 14 19:57, Andrew Stitcher wrote:
> > On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote:
> >> PROTON-660: Fix openssl.c build on windows
> > Are you planning to do this work yourself? If so please take into
> > account my last comments on this bug. I'd work on it myself except that
> > I don't currently have the correct set up. If you can detail the set up
> > (and it's not hard to set up) I'd do it.
> >
> 
> Yep, learning by doing :) What's the most convenient way for the review
> process?
> Patches to the mailing list? links to github commits? apache's reviewboard?
> My guess is the later, except it's the most unfamiliar process to me :)

Reviewboard is currently best as it allows the most granular comments on
the code itself - it can be a pain to set up, but it's usually not too
bad.

If we ever move to a git primary repo then github pull requests might
work too.

> 
> If you want to set up, just build openssl from source (which requires
> ActivePerl iirc)
> and just make sure to install in one of the locations that cmake looks at.

I think that comes into the category of "too much effort"!

> 
> 
> >> PROTON-691: allow proton to be built with add_subdirectory
> > How important is this? The current way to integrate a proton build with
> > another build is via the install directory, this seems to work well.
> >
> It's not super important, just very convenient.

In that case I'd say without a patch to consider (there wasn't one
attached to the JIRA when I looked) it can't be worth holding up 0.8.

> 
> > Is there a specific scenario when you can't run 2 builds with a common
> > install prefix? (This would actually probably make more sense added to
> > the jira itself)
> >
> 
> The idea behind this is to get one build system (esp handy for VS and Xcode)
> 
> We started with two build systems with the intermediate install step.
> Since there always seem to be at least one proton bugfix waiting to go
> upstream,
> we keep track of a patched proton tree as a git submodule. For
> development cycle
> when one is working on said fixes it's really convenient to be able to
> run our tests
> in-tree quickly, skipping the install step. When proton stabilizes, all
> this becomes irrelevant.
> 

I think we are really focusing on getting Proton stabilised, to avoid
this sort of thing.

> I know such approach does not really scale because cmake's symbols are
> not namespaced.
> 
> So, if there is a more proper cmake-istic approach how to achieve a
> similar workflow
> I'd be happy to adapt in that direction.

Not really.

> 
> Bozzo



Re: 0.8 release prep

Posted by Bozo Dragojevic <bo...@digiverse.si>.
On 22. 09. 14 19:57, Andrew Stitcher wrote:
> On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote:
>> PROTON-660: Fix openssl.c build on windows
> Are you planning to do this work yourself? If so please take into
> account my last comments on this bug. I'd work on it myself except that
> I don't currently have the correct set up. If you can detail the set up
> (and it's not hard to set up) I'd do it.
>

Yep, learning by doing :) What's the most convenient way for the review
process?
Patches to the mailing list? links to github commits? apache's reviewboard?
My guess is the later, except it's the most unfamiliar process to me :)

If you want to set up, just build openssl from source (which requires
ActivePerl iirc)
and just make sure to install in one of the locations that cmake looks at.


>> PROTON-691: allow proton to be built with add_subdirectory
> How important is this? The current way to integrate a proton build with
> another build is via the install directory, this seems to work well.
>
It's not super important, just very convenient.

> Is there a specific scenario when you can't run 2 builds with a common
> install prefix? (This would actually probably make more sense added to
> the jira itself)
>

The idea behind this is to get one build system (esp handy for VS and Xcode)

We started with two build systems with the intermediate install step.
Since there always seem to be at least one proton bugfix waiting to go
upstream,
we keep track of a patched proton tree as a git submodule. For
development cycle
when one is working on said fixes it's really convenient to be able to
run our tests
in-tree quickly, skipping the install step. When proton stabilizes, all
this becomes irrelevant.

I know such approach does not really scale because cmake's symbols are
not namespaced.

So, if there is a more proper cmake-istic approach how to achieve a
similar workflow
I'd be happy to adapt in that direction.

Bozzo

Re: 0.8 release prep

Posted by Andrew Stitcher <as...@redhat.com>.
On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote:
> On 18. 09. 14 16:55, Rafael Schloming wrote:
> > Hi Everyone,
> >
> > I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
> > order to triage any remaining issues. If there are any particular issues
> > that you feel strongly should be included in 0.8, please follow up on this
> > thread and bring them to my attention.
> >
> > --Rafael
> >
> I'd like to get these two of mine in
> 
> PROTON-660: Fix openssl.c build on windows

Are you planning to do this work yourself? If so please take into
account my last comments on this bug. I'd work on it myself except that
I don't currently have the correct set up. If you can detail the set up
(and it's not hard to set up) I'd do it.

> PROTON-691: allow proton to be built with add_subdirectory

How important is this? The current way to integrate a proton build with
another build is via the install directory, this seems to work well.

Is there a specific scenario when you can't run 2 builds with a common
install prefix? (This would actually probably make more sense added to
the jira itself)

Andrew



Re: 0.8 release prep

Posted by Bozo Dragojevic <bo...@digiverse.si>.
On 18. 09. 14 16:55, Rafael Schloming wrote:
> Hi Everyone,
>
> I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in
> order to triage any remaining issues. If there are any particular issues
> that you feel strongly should be included in 0.8, please follow up on this
> thread and bring them to my attention.
>
> --Rafael
>
I'd like to get these two of mine in

PROTON-660: Fix openssl.c build on windows
PROTON-691: allow proton to be built with add_subdirectory

Plus the other half of the Windows IOCP work by Cliff

PROTON-684: Restrict IOCP enlistment to pn_selector_t usage scenarios in
Windows

Bozzo