Thanks for the guidance, will keep that in mind :) Sent from my Samsung device. Include original message ---- Original message ---- From: Patricia Shanahan <p...@acm.org> Sent: 02/05/2017 06:28:30 pm To: dev@river.apache.org Subject: Re: [Report] Apache River - Draft
Remember your audience, the ASF board. They care about community and big picture strategy. On 5/2/2017 12:40 AM, Peter wrote: > > 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. > > Cheers, > > Peter. > > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Bryan Thompson <br...@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. > > Thanks, > Bryan > > On Mon, May 1, 2017 at 6:04 AM, Patricia Shanahan <p...@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. >>> >>> >>> > > > > >
