Sent from my iPhone
> On May 13, 2014, at 8:11 AM, Bryan Thompson <[email protected]> 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 classdepandjar). Dennis > > Bryan > >> On May 13, 2014, at 7:10 AM, Dennis Reedy <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>> 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<[email protected]> >>> wrote: >>>>>> >>>>>>> On May 11, 2014, at 12:30 AM, Peter<[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> 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 why >>>>>> 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 been >>> able >>>>>> to do that, at least for maintenance releases, and I don’t see that >>>>>> 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 the >>>>>> 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. >>>
