Re: State of the Project
I've started by modifying the build script to sign jar files, for the new code signing certificate from Symantec. I've been somewhat time poor lately, but am progressing. I will have some new release candidates in the near future. While in the short term this will probably be considered a beta release, in the longer term it pays down technical debt in updating the codebase to Java's current memory model, no longer will minor changes uncover latent race conditions, the code is no longer brittle. Next steps are to allow and encourage interested developers to make improvements. Without change, evolution cannot function and extinction becomes inevitable. Progress only happens with change. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Patricia Shanahan Sent: 20/07/2016 06:28:26 am To: dev@river.apache.org Subject: State of the Project We are due to file a board report next month. Last cycle, I first initiated an open-ended discussion of the state of the project. I included a summary in the board report. The feedback from the board was positive: > mt: Thanks for the frank assessment of River's health. > > sc: +1 to mt: bad news is fine - the fact you're clearly analyzing > and working on it is the great part of this report. I would like to repeat the analysis each quarter, both for my own information and in order to keep the board informed. Any opinions on where we are and where we are going? Thanks, Patricia
State of the Project
We are due to file a board report next month. Last cycle, I first initiated an open-ended discussion of the state of the project. I included a summary in the board report. The feedback from the board was positive: mt: Thanks for the frank assessment of River's health. sc: +1 to mt: bad news is fine - the fact you're clearly analyzing and working on it is the great part of this report. I would like to repeat the analysis each quarter, both for my own information and in order to keep the board informed. Any opinions on where we are and where we are going? Thanks, Patricia
Re: State of the project
In the longer term, my understanding is that the Infrastructure team is working on ways of using Git that are compatible with ASF's IP history requirements. They are running a small experiment with a couple of projects. I will continue to monitor board@ in the hope of adding Git read/write access to the River source code when feasible. On 5/5/2016 5:15 AM, Bryan Thompson wrote: There are several key reasons for moving to git, and a read-only repository would not support most of them: * Git makes it significantly easier to branch and merge when compared to SVN, CVS, etc. * Git pull requests encapsulate an opportunity for feedback on branches and easy diffs between branches that is unparalleled by SVN, etc. * PRs can be contributed more easily from the broader community (but such PRs would require Apache CLAs, etc. before they could be incorporated into an Apache project so we might not get much utility from this). * Git repositories can be easily forked (a read-only view would support this), and these forks can flow updates back to the original project (this would again run into trouble with the Apache CLA process). Thanks, Bryan On Tue, May 3, 2016 at 7:48 AM, Patricia Shanahan wrote: Currently, I believe only read-only Git mirrors are supported for most projects. See http://www.apache.org/dev/git.html. It looks as though the process for adding a mirror is fairly simple. Would that level of support be useful? There is an experiment going on to extend Git use. I suggest at least one of you should subscribe to the infrastructure-dev@ list to follow what is happening. On 5/3/2016 4:22 AM, Tom Hobbs wrote: Could we consider a service registrar that doesn't require code downloads? Other language support? What might it look like? This is my particular itch right now. I’m happy to work on pulling reggie out as one of the first modules. And +1 for git. On 3 May 2016, at 11:29, Peter wrote: Could we consider a service registrar that doesn't require code downloads? Other language support? What might it look like?
Re: State of the project
There are several key reasons for moving to git, and a read-only repository would not support most of them: * Git makes it significantly easier to branch and merge when compared to SVN, CVS, etc. * Git pull requests encapsulate an opportunity for feedback on branches and easy diffs between branches that is unparalleled by SVN, etc. * PRs can be contributed more easily from the broader community (but such PRs would require Apache CLAs, etc. before they could be incorporated into an Apache project so we might not get much utility from this). * Git repositories can be easily forked (a read-only view would support this), and these forks can flow updates back to the original project (this would again run into trouble with the Apache CLA process). Thanks, Bryan On Tue, May 3, 2016 at 7:48 AM, Patricia Shanahan wrote: > Currently, I believe only read-only Git mirrors are supported for most > projects. See http://www.apache.org/dev/git.html. It looks as though the > process for adding a mirror is fairly simple. Would that level of support > be useful? > > There is an experiment going on to extend Git use. I suggest at least one > of you should subscribe to the infrastructure-dev@ list to follow what is > happening. > > On 5/3/2016 4:22 AM, Tom Hobbs wrote: > >> Could we consider a service registrar that doesn't require code >>> downloads? Other language support? What might it look like? >>> >> >> This is my particular itch right now. I’m happy to work on pulling >> reggie out as one of the first modules. >> >> And +1 for git. >> >> >> On 3 May 2016, at 11:29, Peter wrote: >>> >>> Could we consider a service registrar that doesn't require code >>> downloads? Other language support? What might it look like? >>> >> >> >>
Re: State of the project
There's already a read-only Git mirror at https://github.com/apache/river/tree/trunk. Best, Jukka Zitting On Tue, May 3, 2016 at 7:48 AM Patricia Shanahan wrote: > Currently, I believe only read-only Git mirrors are supported for most > projects. See http://www.apache.org/dev/git.html. It looks as though the > process for adding a mirror is fairly simple. Would that level of > support be useful? > > There is an experiment going on to extend Git use. I suggest at least > one of you should subscribe to the infrastructure-dev@ list to follow > what is happening. > > On 5/3/2016 4:22 AM, Tom Hobbs wrote: > >> Could we consider a service registrar that doesn't require code > downloads? Other language support? What might it look like? > > > > This is my particular itch right now. I’m happy to work on pulling > reggie out as one of the first modules. > > > > And +1 for git. > > > > > >> On 3 May 2016, at 11:29, Peter wrote: > >> > >> Could we consider a service registrar that doesn't require code > downloads? Other language support? What might it look like? > > > > >
Re: State of the project
Welcome back Tom, glad to have you on the team again. Sent from my Samsung device. Include original message Original message From: Tom Hobbs Sent: 03/05/2016 09:22:33 pm To: dev@river.apache.org Subject: Re: State of the project > Could we consider a service registrar that doesn't require code downloads? >Other language support? What might it look like? This is my particular itch right now. I’m happy to work on pulling reggie out as one of the first modules. And +1 for git. > On 3 May 2016, at 11:29, Peter wrote: > > Could we consider a service registrar that doesn't require code downloads? >Other language support? What might it look like?
Re: State of the project
It’s a bit difficult to see how/why a read only Git mirror would be useful to us. I suppose it might encourage (or at least, not discourage) adoption by others. Some River committer will still have to officially drag the Git branches into SVN though. > On 3 May 2016, at 12:48, Patricia Shanahan wrote: > > Currently, I believe only read-only Git mirrors are supported for most > projects. See http://www.apache.org/dev/git.html. It looks as though the > process for adding a mirror is fairly simple. Would that level of support be > useful? > > There is an experiment going on to extend Git use. I suggest at least one of > you should subscribe to the infrastructure-dev@ list to follow what is > happening. > > On 5/3/2016 4:22 AM, Tom Hobbs wrote: >>> Could we consider a service registrar that doesn't require code downloads? >>> Other language support? What might it look like? >> >> This is my particular itch right now. I’m happy to work on pulling reggie >> out as one of the first modules. >> >> And +1 for git. >> >> >>> On 3 May 2016, at 11:29, Peter wrote: >>> >>> Could we consider a service registrar that doesn't require code downloads? >>> Other language support? What might it look like? >> >>
Re: State of the project
Currently, I believe only read-only Git mirrors are supported for most projects. See http://www.apache.org/dev/git.html. It looks as though the process for adding a mirror is fairly simple. Would that level of support be useful? There is an experiment going on to extend Git use. I suggest at least one of you should subscribe to the infrastructure-dev@ list to follow what is happening. On 5/3/2016 4:22 AM, Tom Hobbs wrote: Could we consider a service registrar that doesn't require code downloads? Other language support? What might it look like? This is my particular itch right now. I’m happy to work on pulling reggie out as one of the first modules. And +1 for git. On 3 May 2016, at 11:29, Peter wrote: Could we consider a service registrar that doesn't require code downloads? Other language support? What might it look like?
Re: State of the project
> Could we consider a service registrar that doesn't require code downloads? > Other language support? What might it look like? This is my particular itch right now. I’m happy to work on pulling reggie out as one of the first modules. And +1 for git. > On 3 May 2016, at 11:29, Peter wrote: > > Could we consider a service registrar that doesn't require code downloads? > Other language support? What might it look like?
Re: State of the project
Ditto. I'd like to look at how blazegraph uses River, look at building modules, one at a time, from the bottom up, integrating with Rio, is that still an option? Unfortunately when originally proposed it got shot down before I had a chance to comment. I'd also like to look at parts of the api that aren't adequately defined, like Leases, yep an expired lease can be equal to one that hasn't yet? Yes really. I'd like to move to git. I'd like to remove the proxy trust code, that validates after deserializing untrusted foreign data & code. Too complex and way too late. Don't get me wrong, constraints and secure endpoints are good, proxy trust isn't. ProxyTrust was designed to work around the ServiceRegistrar interface that wasn't designed with security considerations in mind. Java 8 default methods allow us to change that. Could we consider a service registrar that doesn't require code downloads? Other language support? What might it look like? The trunk code as it is can be used as the basis for lts, freeing up our ability to innovate, which we need to do to survive. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Tom Hobbs Sent: 03/05/2016 02:50:21 am To: dev@river.apache.org Subject: Re: State of the project I’d sum it up by saying that the project is on life support - but it could pull through. There’s still a release in the pipeline, which hopefully we can get out pretty soon. From that point I think we should revisit carrying on as-is, introducing some radical breaking changes or the attic. > On 2 May 2016, at 11:33, Peter wrote: > > On 2/05/2016 8:59 AM, Patricia Shanahan wrote: >> The next River report to the board is due May 11th. I am supposed to keep >>the board informed of the state of the community. With that in mind, I would >>welcome input from anyone with an opinion on the matter. > > Well it's not looking too healthy, although it appears we still have enough >pmc members to vote (4 active), we've lost a committer recently, interest in >the project is tapering off. > > Most of the code in River is aged between 12 and 18 years old, while the >architectural design principles employed are sound, parts of the api are >showing their age. > > River is tied to Java and is currently deployed in server back end, private >networks. There may be some hope in IoT, however at present we don't support >Android and have limited scope outside of Java. River is also tied to Java >serialization, which has fallen out of favour for newer protocols in recent >times. > > Although some steps have been made toward modularising River, the monolothic >build is hampering development efforts: > Modules allow a development campaign to focus on one module, allowing earlier >completion, followed by review and release of an updated module. The large >monolothic codebase, prolongs a campain, (eg fixing race conditions) and makes >it difficult for other developers to keep up with changes, resulting in >generation of our own FUD and makes it difficult to release often. > > On the plus side our suite of tests are quite comprehensive. > > Regards, > > Peter. >
Re: State of the project
I’d sum it up by saying that the project is on life support - but it could pull through. There’s still a release in the pipeline, which hopefully we can get out pretty soon. From that point I think we should revisit carrying on as-is, introducing some radical breaking changes or the attic. > On 2 May 2016, at 11:33, Peter wrote: > > On 2/05/2016 8:59 AM, Patricia Shanahan wrote: >> The next River report to the board is due May 11th. I am supposed to keep >> the board informed of the state of the community. With that in mind, I would >> welcome input from anyone with an opinion on the matter. > > Well it's not looking too healthy, although it appears we still have enough > pmc members to vote (4 active), we've lost a committer recently, interest in > the project is tapering off. > > Most of the code in River is aged between 12 and 18 years old, while the > architectural design principles employed are sound, parts of the api are > showing their age. > > River is tied to Java and is currently deployed in server back end, private > networks. There may be some hope in IoT, however at present we don't support > Android and have limited scope outside of Java. River is also tied to Java > serialization, which has fallen out of favour for newer protocols in recent > times. > > Although some steps have been made toward modularising River, the monolothic > build is hampering development efforts: > Modules allow a development campaign to focus on one module, allowing earlier > completion, followed by review and release of an updated module. The large > monolothic codebase, prolongs a campain, (eg fixing race conditions) and > makes it difficult for other developers to keep up with changes, resulting in > generation of our own FUD and makes it difficult to release often. > > On the plus side our suite of tests are quite comprehensive. > > Regards, > > Peter. >
Re: State of the project
On 2/05/2016 8:59 AM, Patricia Shanahan wrote: The next River report to the board is due May 11th. I am supposed to keep the board informed of the state of the community. With that in mind, I would welcome input from anyone with an opinion on the matter. Well it's not looking too healthy, although it appears we still have enough pmc members to vote (4 active), we've lost a committer recently, interest in the project is tapering off. Most of the code in River is aged between 12 and 18 years old, while the architectural design principles employed are sound, parts of the api are showing their age. River is tied to Java and is currently deployed in server back end, private networks. There may be some hope in IoT, however at present we don't support Android and have limited scope outside of Java. River is also tied to Java serialization, which has fallen out of favour for newer protocols in recent times. Although some steps have been made toward modularising River, the monolothic build is hampering development efforts: Modules allow a development campaign to focus on one module, allowing earlier completion, followed by review and release of an updated module. The large monolothic codebase, prolongs a campain, (eg fixing race conditions) and makes it difficult for other developers to keep up with changes, resulting in generation of our own FUD and makes it difficult to release often. On the plus side our suite of tests are quite comprehensive. Regards, Peter.
State of the project
The next River report to the board is due May 11th. I am supposed to keep the board informed of the state of the community. With that in mind, I would welcome input from anyone with an opinion on the matter.
