river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: New Chair for Apache River PMC
Date Tue, 13 May 2014 12:26:42 GMT

Sent from my iPhone

> On May 13, 2014, at 8:11 AM, Bryan Thompson <bryan@systap.com> 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 rollback to a known good code base.  I would have to give a -1 to this.  We
need to validate the release against running systems before changing the namespaces.  If that
means keeping this a 2.x release, that's fine.

I think the name change is long over due and applicable with a major version change.

> What is the driver for the maven artifacts?  Is this an apache process issue or a feature
request for some communities?

It was a request by some in the project and also by some that may want to contribute. It also
moves away from the classdepandjar approach (noted you don't need maven to move away from

> Bryan
>> On May 13, 2014, at 7:10 AM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>> 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 13, 2014 at 6:26 AM, Bryan Thompson <bryan@systap.com> wrote:
>>> 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 identified.  The key would be API stability so people could try
>>> it and roll back as necessary for production deployments onto a known good
>>> code base.
>>> Bryan
>>>>> On May 13, 2014, at 3:18 AM, Peter Firmstone <jini@zeus.net.au>
>>>>> 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 static, but not dead. The technology is so
>>>>> worth at least maintaining, fixing bugs and continued care and feeding.
>>>>> The issue to me is that the project has no direction, and River has no
>>>>> community that participates and makes decisions as a community. There
>>> has
>>>>> been tons of work in qa_refactor, is that the future for River? Or is
>>> it a
>>>>> fork?
>>>> There are develpers who are concerned about the number of fixes made in
>>> qa-refactor, but no one yet has identified an issue I haven't been able to
>>> fix very quickly.  In any case the public api and serial form is backward
>>> compatible.
>>>> I encourage the community to test it, find out for themselves and report
>>> any issues.
>>>>> Regards
>>>>> Dennis
>>>>>> On Mon, May 12, 2014 at 9:59 AM, Greg Trasuk<trasukg@stratuscom.com>
>>> wrote:
>>>>>>> On May 11, 2014, at 12:30 AM, Peter<jini@zeus.net.au> 
>>>>>>> Ultimately, if community involvement continues to decline, we
may have
>>>>>> to send River to the attic.
>>>>>>> Distributed computing is difficult and we often bump into the
>>>>>> shortcomings of the java platform, I think these difficulties are
>>>>>> developers have trouble agreeing on solutions.
>>>>>>> But I think more importantly we need increased user involvement.
>>>>>>> Is there any advise or resources we can draw on from other Apache
>>>>>> projects?
>>>>>> It may be, ultimately, that the community has failed and River is
>>> headed
>>>>>> to the Attic.  The usual question is “Can the project round up
the 3
>>> ‘+1’
>>>>>> votes required to make an Apache release?”  Historically, we have
>>> able
>>>>>> to do that, at least for maintenance releases, and I don’t see
>>>>>> changing, at least for a while.
>>>>>> The problem is future development and the ongoing health of the
>>> project.
>>>>>> On this point, we don’t seem to have consensus on where we want
>>>>>> project to go, and there’s limited enthusiasm for user-focused
>>>>>> requirements.  Also, my calls to discuss the health of the project
>>> have had
>>>>>> no response (well, there was a tangent about the build system, but
>>>>>> personally I think that misses the point).
>>>>>> I will include in the board report the fact that no-one has expressed
>>> an
>>>>>> interest in taking over as PMC chair, and ask if there are any other
>>> expert
>>>>>> resources that can help.
>>>>>> Cheers,
>>>>>> Greg Trasuk.

View raw message