Re: New Chair for Apache River PMC

I agree strongly with Bryan here. I do like Rafał's suggested approach of creating a namespace-compatibilty module if the package names will change (which, agreed, is probably long overdue). Making it as easy as possible for the existing (small) user community to run with the new version will enco

Re: New Chair for Apache River PMC

Back when the issue of picking a chair first came up, I said I would take a turn if needed. Of course, I've since dropped out and am no longer eligible. My main reason for dropping out was that I felt there was insufficient user community input and support for a viable project. In particular, I

Re: New Chair for Apache River PMC

+1 - Original message - > Back when the issue of picking a chair first came up, I said I would > take a turn if needed. Of course, I've since dropped out and am no > longer eligible. My main reason for dropping out was that I felt there > was insufficient user community input and supp

Re: New Chair for Apache River PMC

- Original message - > I think also need to decide if qa_refactor does become defacto 3.0, do we > do the following: > > Change the com.sun.jini namespace to org.apache.river I'd like to suggest org.apache.river.impl, so it doesn't stomp all over new api. > Change the com.artima namespac

Re: New Chair for Apache River PMC

Sent from my iPhone > On May 13, 2014, at 11:37 AM, Gregg Wonderly wrote: > > We might want to separate the two paths from a release perspective. > > The namespace changes should happen on a major numbered release. Yes, from 2.x to 3.0. This is the time to do it, not in a minor release 3.0

Re: New Chair for Apache River PMC

+1 > On May 13, 2014, at 11:37 AM, Gregg Wonderly wrote: > > We might want to separate the two paths from a release perspective. > > The namespace changes should happen on a major numbered release. The build > change might be better targeted at 3.1? > > Just my thoughts on making things happ

Re: New Chair for Apache River PMC

Is the name change a requirement for a 3.0? The problem is that this will break compatibility making it extremely difficult to establish performance in existing applications while preserving the ability to rollback to a known good code base. I would have to give a -1 to this. We need to valid

Re: New Chair for Apache River PMC

We might want to separate the two paths from a release perspective. The namespace changes should happen on a major numbered release. The build change might be better targeted at 3.1? Just my thoughts on making things happen sooner with smaller overall number of issues that might then occur and

Re: New Chair for Apache River PMC

So who wants to stand for election as the new chair? Cheers, Greg Trasuk. On May 13, 2014, at 8:46 AM, Bryan Thompson wrote: > Sounds good. > >> On May 13, 2014, at 8:25 AM, Rafał Krupiński >> wrote: >> >> Dnia wtorek, 13 maja 2014 08:11:21 Bryan Thompson pisze: >>> Is the name change a

Re: New Chair for Apache River PMC

I am ok with it as long as the name change can be made transparent. I think that the ability to roll forward and backward production code between the current and the next release trumps everything else. Bryan > On May 13, 2014, at 8:31 AM, Peter wrote: > > - Original message - >> I

Re: New Chair for Apache River PMC

Sounds good. > On May 13, 2014, at 8:25 AM, Rafał Krupiński > wrote: > > Dnia wtorek, 13 maja 2014 08:11:21 Bryan Thompson pisze: >> Is the name change a requirement for a 3.0? The problem is that this will >> break compatibility making it extremely difficult to establish performance >> in ex

Re: New Chair for Apache River PMC

Sent from my iPhone > On May 13, 2014, at 8:11 AM, Bryan Thompson wrote: > > Is the name change a requirement for a 3.0? The problem is that this will > break compatibility making it extremely difficult to establish performance in > existing applications while preserving the ability to roll

Re: New Chair for Apache River PMC

Dnia wtorek, 13 maja 2014 08:11:21 Bryan Thompson pisze: > Is the name change a requirement for a 3.0? The problem is that this will > break compatibility making it extremely difficult to establish performance > in existing applications while preserving the ability to rollback to a > known good co

Build failed in Jenkins: river-qa-refactor-win8 #1

See -- [...truncated 8141 lines...] password: [echo] creating passwords truststore: [exec] Certificate was added to keystore [exec] Certificate was added to keystore [exec] Certif

Re: New Chair for Apache River PMC

I think also need to decide if qa_refactor does become defacto 3.0, do we do the following: Change the com.sun.jini namespace to org.apache.river Change the com.artima namespace to org.apache.river Move to a Maven project and decide on module group and artifact ids Regards Dennis On Tue, May 1

Re: New Chair for Apache River PMC

Why don't we do a pre-release from this branch? Does apache support this concept? Give it some time in the wild to shake down the bugs? If not. Let's just release it and document that there is a lot of churn. Give it a 3.0 designation and be prepared to release a series of updates as bugs are

Re: JERI Scalability Testing

+1 > On May 12, 2014, at 11:03 PM, Gregg Wonderly wrote: > > All of these things are the reason why we just need to take Peter’s hard work > an go with it. There is really no reason to look back. The performance > issues and security problems that Peter has so patiently waded through have >

Re: New Chair for Apache River PMC

On 13/05/2014 9:59 AM, Dennis Reedy wrote: Apologies for not chiming in earlier, I've been running around with my air on fire for the past couple of weeks. As to whether River is dead, I don't think it is, maybe mostly dead (in which case a visit to Miracle Max may be in order). I think River is