river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: [Report] Apache River - Draft
Date Tue, 02 May 2017 07:40:18 GMT
Yes, thanks for the feedback.

Very valid points re production code and modularity, we've built on that by paying back our
technical debt as well.

Once, making a change usually meant a test failure in something unrelated, now the code is
rock solid, making the transition to modularity is/was relatively straightforward as the architecture
is well designed.  The benefits of simplicity and ease of use by changing to the maven build
system is outstanding, new users will no longer have to learn a new build system in order
to utilise River and can digest the api in smaller bites.

Serialization frameworks are being looked at more closely in the aftermath of Java deserialization
flaws and security experts are finding similar problems in other frameworks.

Will focus on the positive and try again.



Sent from my Samsung device.
  Include original message
---- Original message ----
From: Bryan Thompson <bryan@blazegraph.com>
Sent: 01/05/2017 11:27:07 pm
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: [Report] Apache River - Draft

My sense is that it is overly negative.  I think that we made great 
progress on agreeing on a new direction, getting beyond some of the 
deadlocks that were holding back development, new look and feel for the 
site, etc.  It is also significant that committers were added. 

It will take a while to get to the point where the project is "healthy" by

the measure of many active committers.  Breaking down the code into more 
modular build will help.  Focusing on a broad application area (e.g., 
secure IoT) will help.  This is also a project with production grade code, 
which means quite a bit. 

So, I would suggest changing the emphasis to how the project is beginning 
to execute on its new direction, what that direction is, that new 
committers have been added, what they are working on, and how this builds 
towards the project goals and a healthier community. 


On Mon, May 1, 2017 at 6:04 AM, Patricia Shanahan <pats@acm.org> wrote: 

> My first impression is too much technical detail. Also we had a request

> from a board member last month "It would be helpful if you could expand a

> little (a couple of sentences is fine) on the discussions for future 
> directions in your next report.". That needs to be easily identifiable in

> the report. 
> On 5/1/2017 1:26 AM, Peter wrote: 
>> Hi River folks, 
>> Draft board report for May, please make suggestions, remember this is

>> only my point of view, if yours differs please say so.  It's probably a

>> bit wordy, so could use improvement, but I want to be honest with the

>> board about the current state of development. 
>> Regards, 
>> Peter. 
>> <===========================================================> 
>> ## Description: 
>>  - Apache River provides a platform for dynamic discovery and lookup

>> search of network services.  Services may be implemented in a number of

>> languages, while clients are required to be jvm based, to allow proxy

>> jvm byte code to be provisioned dynamically. 
>> ## Issues: 
>>  - River community has over time settled on a stable trunk development

>> model.  The community tends towards risk aversion regarding code 
>> modifications, this has suppressed active development in the past. 
>> - The River 3.0 release included hundreds of internal bug fixes for 
>> latent race conditions, with minimal breaking changes to public api 
>> (com.sun packages renamed to org.apache.river).  We have had one newly

>> introduced bug reported (thread memory leak) since release.  River 3.0

>> was developed in an experimental branch, there were some issues 
>> experienced during merging, which lead to an effort to migrate to git,

>> however that effort has stalled as some members (now emeritus) raised

>> concerns about migration, this requires further investigation and 
>> discussion before it can be resolved. 
>> Some features are being developed outside the project by one pmc member,

>> at the request of another member (also now emeritus) who had raised 
>> objections.  The current plan is to confirm feature stability outside

>> the project and submit diff patches to jira once a feature has been

>> accepted by the community. 
>> We are still waiting for more user feedback regarding the 3.0 release,

>> one user has reported success using River 3.0 with OSGi, while having

>> been unsuccessful with earlier releases.  The com.sun -> 
>> org.apacheriver namespace change has caused breaking changes for 
>> downstream projects, which may be slowing uptake of this release.  A

>> compatibility layer package has been developed externally, while 
>> relatively new, it may assist with uptake for River 3.0. 
>> - If River 3.0 is well recieved, it will likely lead to more confidence

>> and acceptance of new features and experimental development in future.

>> ## Activity: 
>>  - Significant drop in interest since February (205 emails on dev), down

>> to 6 in March and 8 in April.  No more emails on user, no commits since

>> Feb. 
>> - Proposed Release roadmap received positive responses: 
>> Proposed Release roadmap: 
>>>  River 3.0.1 - thread leak fix 
>>>  River 3.1 - Modular build restructure (&  binary release) 
>>>  River 3.2 - Input validation 4 Serialization, delayed unmarshalling&

>>> safe ServiceRegistrar 
>> lookup service. 
>>>  River 3.3 - OSGi support 
>> ## Health report: 
>>  - Little activity at present on dev. 
>>  - No recent commit activity. 
>>  - Development has continued outside the project for contraversial 
>> features (there seems to be more acceptance of these features recently):

>>    * Input validation for java deserialization - prevents DOS and 
>>      Gadget attacks. 
>>    * IPv6 Multicast Service Discovery (River currently only support 
>>      IPv4 multicast discovery). 
>>    * Delayed unmarshalling for Service Lookup and Discovery (includes

>>      SafeServiceRegistrar mentioned in release roadmap), so 
>>      authentication can occur prior to downloading service proxy's,

>>      this addresses a long standing security issue with service lookup

>>      while significantly improving performance under some use cases.

>>    * Security fixes for SSL endpoints, updated to TLS v1.2 with removal

>>      of support for insecure cyphers. 
>>    * Maven build to replace existing ant built that uses 
>>      classdepandjar, a bytecode dependency analysis build tool. 
>>    * Security tool to generate security policy files based on principle

>>      of least privilege, this has been rejected as the system is likely

>>      to be vulnerable to attack while the policy files are being

>>      generated.  The tool was written in response to requests for more

>>      tooling to make River easier to use. 
>> ## PMC changes: 
>>  - Currently 11 PMC members. 
>>  - No new PMC members added in the last 3 months 
>>  - Last PMC addition was Bryan Thompson on Sun Aug 30 2015 
>> ## Committer base changes: 
>>  - Currently 15 committers. 
>>  - Zsolt Kúti was added as a committer on Wed Dec 07 2016 
>>  - Bharath Kumar was added as a committer on the 23th March 2017 
>> ## Releases: 
>>  - River-3.0.0 was released on Wed Oct 05 2016 
>> ## Mailing list activity: 
>>  - Minimal. 
>> ## JIRA activity: 
>> - Nil Activity. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message