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 <[email protected]
<mailto:[email protected]>> wrote:
On May 11, 2014, at 12:30 AM, Peter <[email protected]
<mailto:[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.
--
Jeremy R. Easton-Marks
"être fort pour être utile"
