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 <[email protected]> wrote: > > ----- 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 namespace to org.apache.river > > Perhaps org.apache.river.artima given that it was quite an achievement at > the time. > >> Move to a Maven project and decide on module group and artifact ids > > Or at least a Maven compatible structure. Any ideas what to do with > jsk-policy? Given that this is installed into the ext directory, or into a > directory defined as an extension directory, it is loaded by the extension > classloader. It contains classes that are duplicated by jsk-platform, > considering it's place in the ClassLoader hierarchy, shouldn't jsk-platform > depend on jsk-policy? > > Regards, > > Peter. > >> >> 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. >
