You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2014/05/05 18:04:54 UTC
New Chair for Apache River PMC
Hi all:
A few days ago I posted a request for a new PMC chair. Peter nominated Dennis Reedy. I haven’t seen a response from Dennis accepting the nomination.
Dennis - Are you willing to sit as PMC chair?
Is there anyone else who would like to volunteer?
As soon as we know who’s willing, we should hold a vote for the chair. I suspect the actual vote should probably be on the private list, but nominations should be public.
Cheers,
Greg Trasuk
PMC Chair, Apache River
Re: New Chair for Apache River PMC
Posted by Peter <ji...@zeus.net.au>.
+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 support for a viable project.
> In particular, I was concerned about attempting performance improvement
> with no user workload derived benchmarks.
>
> I have been following the various discussions on the dev mailing list,
> including this one. If you would like me to return and run for chair,
> please reinstate me as a committer and PMC member.
>
> My main agenda would be to find out if there is a sufficient user
> community to make River viable. Without community input, there is no
> rational basis for making decisions, and little point to the whole
> exercise. With an active user community, there would be a path forward.
>
> If any of the active PMC members is even insufficiently reluctant to
> take on being chair, I'll immediately withdraw my candidacy.
>
> I think I may still get the private mailing list. If you wish to discuss
> me behind my back, please include "NOT PATRICIA" in the subject, and
> I'll delete the message without reading it.
>
> Patricia
>
> On 5/13/2014 6:16 AM, Greg Trasuk wrote:
> >
> > So who wants to stand for election as the new chair?
> >
> >
> > Cheers,
> > Greg Trasuk.
> >
> > On May 13, 2014, at 8:46 AM, Bryan Thompson <br...@systap.com> wrote:
> >
> > > Sounds good.
> > >
> > > > On May 13, 2014, at 8:25 AM, Rafał Krupiński
> > > > <ra...@sorcersoft.com> 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 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.
> > > >
> > > > Change namespaces can be made in a compatible way. There could be
> > > > additional jars with empty classes in the old packages that would
> > > > just extend the classes in the new packages, like below:
> > > >
> > > > //some-module.jar
> > > > org.apache.river.SimeClass{
> > > > //class moved from net.jini
> > > > }
> > > >
> > > > //some-module-compat.jar (that depends on some-module.jar)
> > > > net.jini.SomeClass extends org.apache.river.SomeClass{
> > > > //empty class
> > > > }
> > > >
> > > > In order to migrate to the new version, you'd need to replace the
> > > > actual module and add the compatibility module.
> > > >
> > > > Regards
> > > > Rafał
> >
>
Re: New Chair for Apache River PMC
Posted by Patricia Shanahan <pa...@acm.org>.
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 was concerned about attempting performance improvement
with no user workload derived benchmarks.
I have been following the various discussions on the dev mailing list,
including this one. If you would like me to return and run for chair,
please reinstate me as a committer and PMC member.
My main agenda would be to find out if there is a sufficient user
community to make River viable. Without community input, there is no
rational basis for making decisions, and little point to the whole
exercise. With an active user community, there would be a path forward.
If any of the active PMC members is even insufficiently reluctant to
take on being chair, I'll immediately withdraw my candidacy.
I think I may still get the private mailing list. If you wish to discuss
me behind my back, please include "NOT PATRICIA" in the subject, and
I'll delete the message without reading it.
Patricia
On 5/13/2014 6:16 AM, Greg Trasuk wrote:
>
> So who wants to stand for election as the new chair?
>
>
> Cheers,
> Greg Trasuk.
>
> On May 13, 2014, at 8:46 AM, Bryan Thompson <br...@systap.com> wrote:
>
>> Sounds good.
>>
>>> On May 13, 2014, at 8:25 AM, Rafał Krupiński <ra...@sorcersoft.com> 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 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.
>>>
>>> Change namespaces can be made in a compatible way. There could be additional
>>> jars with empty classes in the old packages that would just extend the classes
>>> in the new packages, like below:
>>>
>>> //some-module.jar
>>> org.apache.river.SimeClass{
>>> //class moved from net.jini
>>> }
>>>
>>> //some-module-compat.jar (that depends on some-module.jar)
>>> net.jini.SomeClass extends org.apache.river.SomeClass{
>>> //empty class
>>> }
>>>
>>> In order to migrate to the new version, you'd need to replace the actual
>>> module and add the compatibility module.
>>>
>>> Regards
>>> Rafał
>
Re: New Chair for Apache River PMC
Posted by Greg Trasuk <tr...@stratuscom.com>.
So who wants to stand for election as the new chair?
Cheers,
Greg Trasuk.
On May 13, 2014, at 8:46 AM, Bryan Thompson <br...@systap.com> wrote:
> Sounds good.
>
>> On May 13, 2014, at 8:25 AM, Rafał Krupiński <ra...@sorcersoft.com> 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 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.
>>
>> Change namespaces can be made in a compatible way. There could be additional
>> jars with empty classes in the old packages that would just extend the classes
>> in the new packages, like below:
>>
>> //some-module.jar
>> org.apache.river.SimeClass{
>> //class moved from net.jini
>> }
>>
>> //some-module-compat.jar (that depends on some-module.jar)
>> net.jini.SomeClass extends org.apache.river.SomeClass{
>> //empty class
>> }
>>
>> In order to migrate to the new version, you'd need to replace the actual
>> module and add the compatibility module.
>>
>> Regards
>> Rafał
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
Sounds good.
> On May 13, 2014, at 8:25 AM, Rafał Krupiński <ra...@sorcersoft.com> 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 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.
>
> Change namespaces can be made in a compatible way. There could be additional
> jars with empty classes in the old packages that would just extend the classes
> in the new packages, like below:
>
> //some-module.jar
> org.apache.river.SimeClass{
> //class moved from net.jini
> }
>
> //some-module-compat.jar (that depends on some-module.jar)
> net.jini.SomeClass extends org.apache.river.SomeClass{
> //empty class
> }
>
> In order to migrate to the new version, you'd need to replace the actual
> module and add the compatibility module.
>
> Regards
> Rafał
Re: New Chair for Apache River PMC
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
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 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.
Change namespaces can be made in a compatible way. There could be additional
jars with empty classes in the old packages that would just extend the classes
in the new packages, like below:
//some-module.jar
org.apache.river.SimeClass{
//class moved from net.jini
}
//some-module-compat.jar (that depends on some-module.jar)
net.jini.SomeClass extends org.apache.river.SomeClass{
//empty class
}
In order to migrate to the new version, you'd need to replace the actual
module and add the compatibility module.
Regards
Rafał
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
Works for me. Has compatibility, concurrency bug fixes, and performance gains,
Bryan
> On May 14, 2014, at 6:58 AM, Michał Kłeczek <mi...@xpro.biz> wrote:
>
> That is going to cause qa_refactor merge difficult.
>
> My take - pretty radical - on this would be:
>
> 1. Rename branch trunk to "2.x.x"
> - 2.x would enter "legacy maintanance" mode
> 2. Rename qa_refactor to "trunk"
> 3. Rename packages in "trunk", introduce compatibility jars
> 4. Release 3.0.0-alpha from "trunk"
> 4.a test test test chase bugs :)
> 5. Depending on how the community feels modular (mavenized) build is important
> - modify "trunk" before final 3.0.0 release (this can be postponed until after
> 3.0.0)
> 6. Release 3.0.0 from trunk
>
> The problem right now is that it is unclear what branch should be a base for
> any work that potentially is going to be included in 3.x.x - is it qa_refactor
> or is it trunk?
> So we need an official 3.x.x branch ASAP.
>
> I really think work done in qa_refactor is important enough to make it the
> main development branch. The community seems to agree that sooner or later it
> _will_ be merged.
>
> Regards,
> Michal
>
>> On Wednesday 14 of May 2014 11:52:32 Rafał Krupiński wrote:
>> Dnia środa, 14 maja 2014 18:50:28 Peter Firmstone pisze:
>>> Perhaps we should postpone the rename for now.
>>
>> Actually, 3.0 is the only moment to change the names of classes, as it
>> breaks compatibility and strongly suggests new major version number.
>>
>> May I suggest another approach to the roadmap:
>>
>> Release +1 - modularized build, no code change - full binary compatibility.
>>
>> Release +2 - change the namespaces and class names, if any. Introduce
>> compatibility jars.
>>
>> Release +3 - merge/replace with the qa_refactor.
>>
>> Regards
>> Rafał
>
Re: New Chair for Apache River PMC
Posted by Michał Kłeczek <mi...@xpro.biz>.
That is going to cause qa_refactor merge difficult.
My take - pretty radical - on this would be:
1. Rename branch trunk to "2.x.x"
- 2.x would enter "legacy maintanance" mode
2. Rename qa_refactor to "trunk"
3. Rename packages in "trunk", introduce compatibility jars
4. Release 3.0.0-alpha from "trunk"
4.a test test test chase bugs :)
5. Depending on how the community feels modular (mavenized) build is important
- modify "trunk" before final 3.0.0 release (this can be postponed until after
3.0.0)
6. Release 3.0.0 from trunk
The problem right now is that it is unclear what branch should be a base for
any work that potentially is going to be included in 3.x.x - is it qa_refactor
or is it trunk?
So we need an official 3.x.x branch ASAP.
I really think work done in qa_refactor is important enough to make it the
main development branch. The community seems to agree that sooner or later it
_will_ be merged.
Regards,
Michal
On Wednesday 14 of May 2014 11:52:32 Rafał Krupiński wrote:
> Dnia środa, 14 maja 2014 18:50:28 Peter Firmstone pisze:
> > Perhaps we should postpone the rename for now.
>
> Actually, 3.0 is the only moment to change the names of classes, as it
> breaks compatibility and strongly suggests new major version number.
>
> May I suggest another approach to the roadmap:
>
> Release +1 - modularized build, no code change - full binary compatibility.
>
> Release +2 - change the namespaces and class names, if any. Introduce
> compatibility jars.
>
> Release +3 - merge/replace with the qa_refactor.
>
> Regards
> Rafał
Re: New Chair for Apache River PMC
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia środa, 14 maja 2014 06:26:26 Bryan Thompson pisze:
> What is the argument for pushing out the qa_refactor based release? Do you
> believe that it is not ready to evaluate in production systems? Or do you
> believe that the rename is more important? If so, why? Just curious about
> people's perspectives here.
These changes (build and rename) can be made to current branch. It will be
easier to find any problems with the migration, if any.
Regards
Rafał
Re: New Chair for Apache River PMC
Posted by Tom Hobbs <tv...@googlemail.com>.
+1 for cutting qa_refactor to become 3.0 trunk. I agree that doing the
package rename at the same time makes sense. I'm less fussed about the
modular build change.
+1 for Patricia as PMC chair, she sounds like she has a (positive) agenda.
On Thursday, May 15, 2014, Gregg Wonderly <ge...@cox.net> wrote:
> There is little total value in doing anything to the non qa_refactor
code. It is what it is, and should just be left as it is for use of
anyone who might still want to use it for some odd reason.
>
> It would be best to just spend the effort on making qa_refactor into the
3.0.0 release.
>
> Peter has stated that there are no compatibility issues with the code in
qa_refactor. He understand the API/source as well as the binary
compatibility issue, and the binary compatibility is the larger issue for
“evaluating” this codebase in any existing environment.
>
> The suggestion for use a compatibility layer for the rename takes care of
that issue.
>
> That just leaves it up to the community to jump in and do testing.
>
> I would strongly suggest that community testing should operate off of the
existing testing infrastructure, and we would want to extend those tests
with anything that we believe our own software might depend on working
appropriately so that others can help with that testing, as well as having
such dependencies documented in the test suite that will help keep that
compatibility in place for the future.
>
> Gregg
>
> On May 14, 2014, at 9:04 AM, Rafał Krupiński <
rafal.krupinski@sorcersoft.com> wrote:
>
>> Dnia środa, 14 maja 2014 06:26:26 Bryan Thompson pisze:
>>> What is the argument for pushing out the qa_refactor based release? Do
you
>>> believe that it is not ready to evaluate in production systems? Or do
you
>>> believe that the rename is more important? If so, why? Just curious
about
>>> people's perspectives here.
>>
>> These changes (build and rename) can be made to current branch. It will
be
>> easier to find any problems with the migration, if any.
>>
>> Regards
>> Rafał
>
>
Re: New Chair for Apache River PMC
Posted by Gregg Wonderly <ge...@cox.net>.
There is little total value in doing anything to the non qa_refactor code. It is what it is, and should just be left as it is for use of anyone who might still want to use it for some odd reason.
It would be best to just spend the effort on making qa_refactor into the 3.0.0 release.
Peter has stated that there are no compatibility issues with the code in qa_refactor. He understand the API/source as well as the binary compatibility issue, and the binary compatibility is the larger issue for “evaluating” this codebase in any existing environment.
The suggestion for use a compatibility layer for the rename takes care of that issue.
That just leaves it up to the community to jump in and do testing.
I would strongly suggest that community testing should operate off of the existing testing infrastructure, and we would want to extend those tests with anything that we believe our own software might depend on working appropriately so that others can help with that testing, as well as having such dependencies documented in the test suite that will help keep that compatibility in place for the future.
Gregg
On May 14, 2014, at 9:04 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
> Dnia środa, 14 maja 2014 06:26:26 Bryan Thompson pisze:
>> What is the argument for pushing out the qa_refactor based release? Do you
>> believe that it is not ready to evaluate in production systems? Or do you
>> believe that the rename is more important? If so, why? Just curious about
>> people's perspectives here.
>
> These changes (build and rename) can be made to current branch. It will be
> easier to find any problems with the migration, if any.
>
> Regards
> Rafał
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
What is the argument for pushing out the qa_refactor based release? Do you believe that it is not ready to evaluate in production systems? Or do you believe that the rename is more important? If so, why? Just curious about people's perspectives here.
Bryan
> On May 14, 2014, at 5:52 AM, Rafał Krupiński <ra...@sorcersoft.com> wrote:
>
> Dnia środa, 14 maja 2014 18:50:28 Peter Firmstone pisze:
>> Perhaps we should postpone the rename for now.
>
> Actually, 3.0 is the only moment to change the names of classes, as it breaks
> compatibility and strongly suggests new major version number.
>
> May I suggest another approach to the roadmap:
>
> Release +1 - modularized build, no code change - full binary compatibility.
>
> Release +2 - change the namespaces and class names, if any. Introduce
> compatibility jars.
>
> Release +3 - merge/replace with the qa_refactor.
>
> Regards
> Rafał
Re: New Chair for Apache River PMC
Posted by Rafał Krupiński <ra...@sorcersoft.com>.
Dnia środa, 14 maja 2014 18:50:28 Peter Firmstone pisze:
> Perhaps we should postpone the rename for now.
Actually, 3.0 is the only moment to change the names of classes, as it breaks
compatibility and strongly suggests new major version number.
May I suggest another approach to the roadmap:
Release +1 - modularized build, no code change - full binary compatibility.
Release +2 - change the namespaces and class names, if any. Introduce
compatibility jars.
Release +3 - merge/replace with the qa_refactor.
Regards
Rafał
Re: New Chair for Apache River PMC
Posted by Peter Firmstone <ji...@zeus.net.au>.
Perhaps we should postpone the rename for now.
On 14/05/2014 4:55 PM, Dawid Loubser wrote:
> 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 encourage verification of the quality - or
> bugs - as soon as possible.
>
> Dawid
>
>
> On 13/05/2014 14:46, Bryan Thompson wrote:
>> I think that the ability to roll forward and backward production code between the current and the next release trumps everything else.
Re: New Chair for Apache River PMC
Posted by Dawid Loubser <da...@travellinck.com>.
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 encourage verification of the quality - or
bugs - as soon as possible.
Dawid
On 13/05/2014 14:46, Bryan Thompson wrote:
> I think that the ability to roll forward and backward production code between the current and the next release trumps everything else.
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
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 <ji...@zeus.net.au> 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 <br...@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 <ji...@zeus.net.au>
>>>> 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<tr...@stratuscom.com>
>>> wrote:
>>>>>>
>>>>>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
>
Re: New Chair for Apache River PMC
Posted by Peter <ji...@zeus.net.au>.
----- 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 <br...@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 <ji...@zeus.net.au>
> > > 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<tr...@stratuscom.com>
> > wrote:
> > > > >
> > > > > > On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
> > >
> >
Re: New Chair for Apache River PMC
Posted by Dennis Reedy <de...@gmail.com>.
Sent from my iPhone
> On May 13, 2014, at 8:11 AM, Bryan Thompson <br...@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 classdepandjar).
Dennis
>
> Bryan
>
>> On May 13, 2014, at 7:10 AM, Dennis Reedy <de...@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 <br...@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 <ji...@zeus.net.au> 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<tr...@stratuscom.com>
>>> wrote:
>>>>>>
>>>>>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
>>>
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
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.
What is the driver for the maven artifacts? Is this an apache process issue or a feature request for some communities?
Bryan
> On May 13, 2014, at 7:10 AM, Dennis Reedy <de...@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 <br...@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 <ji...@zeus.net.au> 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<tr...@stratuscom.com>
>> wrote:
>>>>>
>>>>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
>>
Re: New Chair for Apache River PMC
Posted by Dennis Reedy <de...@gmail.com>.
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 <br...@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 <ji...@zeus.net.au> 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<tr...@stratuscom.com>
> wrote:
> >>>
> >>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
> >
>
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
+1
> On May 13, 2014, at 11:37 AM, Gregg Wonderly <ge...@cox.net> 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 happen sooner with smaller overall number of issues that might then occur and need fixes.
>
> If 3.0 is too volatile, that won't be good!
>
> Gregg
>
> Sent from my iPhone
>
>> On May 13, 2014, at 6:10 AM, Dennis Reedy <de...@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 <br...@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 <ji...@zeus.net.au> 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<tr...@stratuscom.com>
>>> wrote:
>>>>>>
>>>>>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
>>>
Re: New Chair for Apache River PMC
Posted by Dennis Reedy <de...@gmail.com>.
Sent from my iPhone
> On May 13, 2014, at 11:37 AM, Gregg Wonderly <ge...@cox.net> 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 to 3.1
Dennis
Re: New Chair for Apache River PMC
Posted by Gregg Wonderly <ge...@cox.net>.
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 need fixes.
If 3.0 is too volatile, that won't be good!
Gregg
Sent from my iPhone
> On May 13, 2014, at 6:10 AM, Dennis Reedy <de...@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 <br...@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 <ji...@zeus.net.au> 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<tr...@stratuscom.com>
>> wrote:
>>>>>
>>>>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
>>>
>>
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
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 <ji...@zeus.net.au> 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<tr...@stratuscom.com> wrote:
>>>
>>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
>
Re: New Chair for Apache River PMC
Posted by Peter Firmstone <ji...@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<tr...@stratuscom.com> wrote:
>
>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
Re: New Chair for Apache River PMC
Posted by Dennis Reedy <de...@gmail.com>.
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?
Regards
Dennis
On Mon, May 12, 2014 at 9:59 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> On May 11, 2014, at 12:30 AM, Peter <ji...@zeus.net.au> 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.
Re: New Chair for Apache River PMC
Posted by Peter Firmstone <ji...@zeus.net.au>.
I think it would be interesting to have a discussion about any
shortcomings in the api and how things might be done differently with
modern knowledge, to determine whether we need to redesign the api and
if the extent required a full rewrite or just a backward compatiblity break.
So far I've managed to modernise the internals with promising results.
I'm working on a bug in JERI at present. The public API has remained
compatible in keeping with general consensus. I have a hard enough time
changing private code, the list is very conservative with change.
Regards,
Peter.
On 13/05/2014 12:21 AM, Jeremy R. Easton-Marks wrote:
> While I enjoy River I think that shelving it as is may be the best
> option. I think this project may have run its course in its current
> state and this doesn't encourage new development or interest in
> participating in the project.
>
> However, I would like to present a strawman proposal to the group. The
> current committers put out a last maintenance release fixing any bugs
> that may have been been resolved but not yet released. After that the
> 2.* branch is abandoned. At that point the River community decides if
> it is possible and worthwhile to start over from scratch. We begin
> this new project from day 1 with deciding what we want to accomplish,
> and how we accomplish. No code is written until a good set of
> requirements are written and voted upon. We keep the development
> community in mind and make sure that River 3.0 is approachable from
> scratch.
>
> While this may take more time and at times probably be very tedious at
> times I think it gives the project a fresh start and not be beholden
> to old code, and requirements.
>
> Just my 2 cents on the subject.
>
> ~Jeremy
>
>
> On Mon, May 12, 2014 at 8:59 AM, Greg Trasuk <trasukg@stratuscom.com
> <ma...@stratuscom.com>> wrote:
>
>
> On May 11, 2014, at 12:30 AM, Peter <jini@zeus.net.au
> <ma...@zeus.net.au>> 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.
>
>
>
>
> --
> Jeremy R. Easton-Marks
>
> "être fort pour être utile"
Re: New Chair for Apache River PMC
Posted by "Jeremy R. Easton-Marks" <J....@gmail.com>.
While I enjoy River I think that shelving it as is may be the best option.
I think this project may have run its course in its current state and this
doesn't encourage new development or interest in participating in the
project.
However, I would like to present a strawman proposal to the group. The
current committers put out a last maintenance release fixing any bugs that
may have been been resolved but not yet released. After that the 2.* branch
is abandoned. At that point the River community decides if it is possible
and worthwhile to start over from scratch. We begin this new project from
day 1 with deciding what we want to accomplish, and how we accomplish. No
code is written until a good set of requirements are written and voted
upon. We keep the development community in mind and make sure that River
3.0 is approachable from scratch.
While this may take more time and at times probably be very tedious at
times I think it gives the project a fresh start and not be beholden to old
code, and requirements.
Just my 2 cents on the subject.
~Jeremy
On Mon, May 12, 2014 at 8:59 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> On May 11, 2014, at 12:30 AM, Peter <ji...@zeus.net.au> 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.
--
Jeremy R. Easton-Marks
"être fort pour être utile"
Re: New Chair for Apache River PMC
Posted by Peter Firmstone <ji...@zeus.net.au>.
I think I've been heading slowly in that general direction; I'm still
fixing bugs. Because there are ongoing concerns regarding the number of
internal changes to modernise the code (public api compatible), there's
no plan to make this a public release, but instead allow the community
to decide what to do with the code, there is significant support to make
these improvements, it's just the migration process is a source of
contention. I do plan to produce release candidates for wider testing
in the near future however.
What I've worked on:
1. Distributed objects, to replace Serializable, instead of using
reflection to serialize an objects serial form, it serializes
instructions to recreate objects remotely using method calls and
arguments. So now you can extend objects that aren't Serializable
without a zero arg constructor and implement Distributed, and you
can check invariants, copy arrays and Collections AND have final
fields.
2. Fixing Bugs, lots of bugs
3. Eliminating unnecessary DNS calls.
4. Making security scalable.
5. We need access to decent hardware to perform real world testing.
What I'd like to do:
1. UDT Sockets
2. DNS-SRV Lookup Discovery
3. Distributed Lambda Expressions
4. Modular build
Good to hear River is still useful.
Regards,
Peter.
On 13/05/2014 12:54 AM, Bryan Thompson wrote:
> We have been using river/jini since 2006. While I have very little time for work on open source projects outside of our own (read - completely swamped), I am hugely in favor of its continued life. The main points for me are not so much the evolution of the software as continuing to harden an already great platform such that it can continue to be used.
>
> Thanks,
> Bryan
>
>> On May 12, 2014, at 9:59 AM, Greg Trasuk<tr...@stratuscom.com> wrote:
>>
>>
>>> On May 11, 2014, at 12:30 AM, Peter<ji...@zeus.net.au> 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.
Re: New Chair for Apache River PMC
Posted by Bryan Thompson <br...@systap.com>.
We have been using river/jini since 2006. While I have very little time for work on open source projects outside of our own (read - completely swamped), I am hugely in favor of its continued life. The main points for me are not so much the evolution of the software as continuing to harden an already great platform such that it can continue to be used.
Thanks,
Bryan
> On May 12, 2014, at 9:59 AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>
>> On May 11, 2014, at 12:30 AM, Peter <ji...@zeus.net.au> 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.
Re: New Chair for Apache River PMC
Posted by Greg Trasuk <tr...@stratuscom.com>.
On May 11, 2014, at 12:30 AM, Peter <ji...@zeus.net.au> 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.
Re: New Chair for Apache River PMC
Posted by Peter <ji...@zeus.net.au>.
Greg,
I think this is a position that has to be earned, rather than one to volunteer for.
Having said that, the community has remained silent on the issue, which tends to indicate either none of the remaining developers have the confidence of the community or that River has lost community interest.
Although there are times when we haven't seen eye to eye, you've made significant contributions of time and effort; performing maintenance releases and rewriting a new surrogate architecture implementation from the ground up.
If time is a problem, I can lodge board reports on your behalf.
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?
Regards,
Peter.
----- Original message -----
> Hi all:
>
> A few days ago I posted a request for a new PMC chair. Peter nominated
> Dennis Reedy. I haven’t seen a response from Dennis accepting the
> nomination.
>
> Dennis - Are you willing to sit as PMC chair?
> Is there anyone else who would like to volunteer?
>
> As soon as we know who’s willing, we should hold a vote for the chair.
> I suspect the actual vote should probably be on the private list, but
> nominations should be public.
>
> Cheers,
>
> Greg Trasuk
> PMC Chair, Apache River
Re: New Chair for Apache River PMC
Posted by Dennis Reedy <de...@gmail.com>.
On May 5, 2014, at 1204PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> Hi all:
>
> A few days ago I posted a request for a new PMC chair. Peter nominated Dennis Reedy. I haven’t seen a response from Dennis accepting the nomination.
>
> Dennis - Are you willing to sit as PMC chair?
Apologies for the delay in responding. While I appreciate the nomination, at this point I dont think I can accept the position.
Thanks and regards
Dennis
Re: New Chair for Apache River PMC
Posted by Dennis Reedy <de...@gmail.com>.
On May 5, 2014, at 1204PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> Hi all:
>
> A few days ago I posted a request for a new PMC chair. Peter nominated Dennis Reedy. I haven’t seen a response from Dennis accepting the nomination.
>
> Dennis - Are you willing to sit as PMC chair?
Apologies for the delay in responding. While I appreciate the nomination, at this point I dont think I can accept the position.
Thanks and regards
Dennis