You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <pe...@zeus.net.au> on 2020/10/09 23:03:13 UTC

[VOTE]: make trunk an unstable development branch.

Currently the trunk branch is a stable branch, it is not for development 
code, let's make it so we can develop in trunk.  The vote concludes in 
two weeks.

+1 Peter.

Rationale:

The project needs to migrate from SVN to GIT.

The trunk branch is the GIT branch, currently it's only read only but we 
can make it a live writable git repository simply with an INFRA JIRA ticket.

https://github.com/apache/river

If we allow the trunk branch to become a development branch, then we can 
move the current modular develpment branch into trunk, and migrate other 
components not currently in the trunk branch like the ldj-tests, 
surrogate and other bits and pieces, which are also in a development 
state not ready for release.  Note that these should probably go under 
their own directory in trunk.

Doing this will preserve the commit history of Apache River.

Are there any git experts on the list?

If this is not the right way to go about the migration to git, please 
give us your thoughts?

Regards,

Peter.


Re: [VOTE]: make trunk an unstable development branch.

Posted by Peter Firmstone <pe...@zeus.net.au>.
If this vote fails, I will instead raise a Jira INFRA ticket to base the 
root of the git repository on:

https://svn.apache.org/repos/asf/river/

Actually is that a better idea?   The negative is there are 11 forks of 
Apache River on github and I don't know what impact it will have.

Regards,

Peter.

On 10/10/2020 9:03 AM, Peter Firmstone wrote:
> Currently the trunk branch is a stable branch, it is not for 
> development code, let's make it so we can develop in trunk.  The vote 
> concludes in two weeks.
>
> +1 Peter.
>
> Rationale:
>
> The project needs to migrate from SVN to GIT.
>
> The trunk branch is the GIT branch, currently it's only read only but 
> we can make it a live writable git repository simply with an INFRA 
> JIRA ticket.
>
> https://github.com/apache/river
>
> If we allow the trunk branch to become a development branch, then we 
> can move the current modular develpment branch into trunk, and migrate 
> other components not currently in the trunk branch like the ldj-tests, 
> surrogate and other bits and pieces, which are also in a development 
> state not ready for release.  Note that these should probably go under 
> their own directory in trunk.
>
> Doing this will preserve the commit history of Apache River.
>
> Are there any git experts on the list?
>
> If this is not the right way to go about the migration to git, please 
> give us your thoughts?
>
> Regards,
>
> Peter.
>

[RESULT] Re: [VOTE]: make trunk an unstable development branch.

Posted by Peter Firmstone <pe...@zeus.net.au>.
The vote passes with 4 binding and 1 non binding:

+1 Dan Rollo

+1 Dennis Reedy

+1 Phillip Rhodes (non binding)

+1 Bryan Thompson

+1 Peter Firmstone

Regards,

Peter.

On 10/15/2020 12:12 AM, danrollo@gmail.com wrote:
> +1
>
>> On Oct 14, 2020, at 8:57 AM, Dennis Reedy <de...@gmail.com> wrote:
>>
>> +1
>>
>>>> On Oct 12, 2020, at 10:23 PM, Phillip Rhodes <mo...@gmail.com> wrote:
>>>>
>>>> On Fri, Oct 9, 2020 at 7:03 PM Peter Firmstone
>>>> <pe...@zeus.net.au> wrote:
>>>>
>>>> Currently the trunk branch is a stable branch, it is not for development
>>>> code, let's make it so we can develop in trunk.  The vote concludes in
>>>> two weeks.
>>> +1 (non-binding) from me
>>>
>>> Phil

Re: [VOTE]: make trunk an unstable development branch.

Posted by da...@gmail.com.
+1

> On Oct 14, 2020, at 8:57 AM, Dennis Reedy <de...@gmail.com> wrote:
> 
> +1
> 
>>> On Oct 12, 2020, at 10:23 PM, Phillip Rhodes <mo...@gmail.com> wrote:
>>> 
>>> On Fri, Oct 9, 2020 at 7:03 PM Peter Firmstone
>>> <pe...@zeus.net.au> wrote:
>>> 
>>> Currently the trunk branch is a stable branch, it is not for development
>>> code, let's make it so we can develop in trunk.  The vote concludes in
>>> two weeks.
>> 
>> +1 (non-binding) from me
>> 
>> Phil

Re: [VOTE]: make trunk an unstable development branch.

Posted by Dennis Reedy <de...@gmail.com>.
+1

> On Oct 12, 2020, at 10:23 PM, Phillip Rhodes <mo...@gmail.com> wrote:
> 
> On Fri, Oct 9, 2020 at 7:03 PM Peter Firmstone
> <pe...@zeus.net.au> wrote:
>> 
>> Currently the trunk branch is a stable branch, it is not for development
>> code, let's make it so we can develop in trunk.  The vote concludes in
>> two weeks.
> 
> +1 (non-binding) from me
> 
> Phil

Re: [VOTE]: make trunk an unstable development branch.

Posted by Phillip Rhodes <mo...@gmail.com>.
On Fri, Oct 9, 2020 at 7:03 PM Peter Firmstone
<pe...@zeus.net.au> wrote:
>
> Currently the trunk branch is a stable branch, it is not for development
> code, let's make it so we can develop in trunk.  The vote concludes in
> two weeks.

+1 (non-binding) from me

Phil

Development Environment

Posted by Peter Firmstone <pe...@zeus.net.au>.
Thanks Bryan,

On 10/11/2020 8:18 AM, Bryan Thompson wrote:
> +1. It sounds like this addresses concerns for moving to GitHub.
>
> Question: will this help people to find the right development environment
> or do we need to do something more to enable that?

It will help, however to achieve that goal, we need to document the new 
practices of modular development with River, not only have the build 
tools changed, but development has too, for example exporting services; 
the old way a service was exported was during construction, which lets 
the service's "this" reference to escape before the constructor has 
completed and any final fields are frozen.  There are a lot of Jini 
books out there, where the standard way of doing things contain bad 
practices.  While it's been discussed on this list, there are no easily 
accessible documents containing best practices.

We also need to show people how to code their services, so that should 
they wish to secure them at a later date, they only need change their 
configuration, this is actually very simple, but I don't think many 
people are aware of the details.

When people think of secure services they remember the complexity of 
proxy trust, which turns out, thanks to the insecurity of Java 
Serialization (which thankfully is now clearly true and unquestionable), 
is both completely useless and unnecessary.   To be fair, the developers 
of Jini, who also created Java Serialization must have assumed that it 
would be maintained in such a way to address security issues as they arose.

Of course River is not yet secure, but the security issues have been 
solved now outside the project in ways that also reduce complexity and 
improve performance, which can be used by River as a prototype to create 
an even better implementation.

Without diverging too far down a tangent, the last time I had a 
discussion with Java's developers, they were not ready to give up 
deserialization of object graphs with circular references, which 
prevents validation of invariant's during deserialization prior to 
object construction, this discussion was prior to the current serial 
filters implementation.  An example of an object graph that contains a 
circular reference is Throwable, it contains a reference to itself.  But 
I've found it possible to wire up circular references, without requiring 
the serialization framework to support it.   The advantage that Java 
serialization has over other frameworks, is the transmission of object 
graphs, that is objects, not just primitive types, and that is the basis 
of River.  As a result people are turning to serialization frameworks 
that only support serialization of primitive values.  However 
serialization of object graphs can be secure, if we give up transmission 
of circular references, leaving it up to the objects themselves to wire 
up the circular links afterwards.  But for now, Java serialization is 
best thought of as a tool that allows the originator of the serialized 
data to create any object they like using any parameters they like.

The way I solved Java serialization's known insecurities was to take the 
serialization framework from Apache Harmony, and re-implement 
deserialization after studying known vulnerabilities.

Cheers,

Peter.

>
> On Sat, Oct 10, 2020 at 15:10 Peter Firmstone <pe...@zeus.net.au>
> wrote:
>
>> Some additional rationale:
>>
>> The original reason some people wanted a stable trunk branch was they
>> were concerned about the pace of development moving too fast, clearly
>> that's no longer a problem, now the stable development branch has become
>> an impediment as people on github can't see the development we are doing.
>>
>> Even Apache board members looked at github and thought we had no commits
>> for 3 years.
>>
>> We need people to see the ongoing work on River, so they have confidence
>> in the project's future and it's continued development and support.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 10/10/2020 9:03 AM, Peter Firmstone wrote:
>>> Currently the trunk branch is a stable branch, it is not for
>>> development code, let's make it so we can develop in trunk.  The vote
>>> concludes in two weeks.
>>>
>>> +1 Peter.
>>>
>>> Rationale:
>>>
>>> The project needs to migrate from SVN to GIT.
>>>
>>> The trunk branch is the GIT branch, currently it's only read only but
>>> we can make it a live writable git repository simply with an INFRA
>>> JIRA ticket.
>>>
>>> https://github.com/apache/river
>>>
>>> If we allow the trunk branch to become a development branch, then we
>>> can move the current modular develpment branch into trunk, and migrate
>>> other components not currently in the trunk branch like the ldj-tests,
>>> surrogate and other bits and pieces, which are also in a development
>>> state not ready for release.  Note that these should probably go under
>>> their own directory in trunk.
>>>
>>> Doing this will preserve the commit history of Apache River.
>>>
>>> Are there any git experts on the list?
>>>
>>> If this is not the right way to go about the migration to git, please
>>> give us your thoughts?
>>>
>>> Regards,
>>>
>>> Peter.
>>>

Re: [VOTE]: make trunk an unstable development branch.

Posted by Bryan Thompson <br...@blazegraph.com>.
+1. It sounds like this addresses concerns for moving to GitHub.

Question: will this help people to find the right development environment
or do we need to do something more to enable that?

On Sat, Oct 10, 2020 at 15:10 Peter Firmstone <pe...@zeus.net.au>
wrote:

> Some additional rationale:
>
> The original reason some people wanted a stable trunk branch was they
> were concerned about the pace of development moving too fast, clearly
> that's no longer a problem, now the stable development branch has become
> an impediment as people on github can't see the development we are doing.
>
> Even Apache board members looked at github and thought we had no commits
> for 3 years.
>
> We need people to see the ongoing work on River, so they have confidence
> in the project's future and it's continued development and support.
>
> Cheers,
>
> Peter.
>
> On 10/10/2020 9:03 AM, Peter Firmstone wrote:
> > Currently the trunk branch is a stable branch, it is not for
> > development code, let's make it so we can develop in trunk.  The vote
> > concludes in two weeks.
> >
> > +1 Peter.
> >
> > Rationale:
> >
> > The project needs to migrate from SVN to GIT.
> >
> > The trunk branch is the GIT branch, currently it's only read only but
> > we can make it a live writable git repository simply with an INFRA
> > JIRA ticket.
> >
> > https://github.com/apache/river
> >
> > If we allow the trunk branch to become a development branch, then we
> > can move the current modular develpment branch into trunk, and migrate
> > other components not currently in the trunk branch like the ldj-tests,
> > surrogate and other bits and pieces, which are also in a development
> > state not ready for release.  Note that these should probably go under
> > their own directory in trunk.
> >
> > Doing this will preserve the commit history of Apache River.
> >
> > Are there any git experts on the list?
> >
> > If this is not the right way to go about the migration to git, please
> > give us your thoughts?
> >
> > Regards,
> >
> > Peter.
> >
>

Re: [VOTE]: make trunk an unstable development branch.

Posted by Peter Firmstone <pe...@zeus.net.au>.
Some additional rationale:

The original reason some people wanted a stable trunk branch was they 
were concerned about the pace of development moving too fast, clearly 
that's no longer a problem, now the stable development branch has become 
an impediment as people on github can't see the development we are doing.

Even Apache board members looked at github and thought we had no commits 
for 3 years.

We need people to see the ongoing work on River, so they have confidence 
in the project's future and it's continued development and support.

Cheers,

Peter.

On 10/10/2020 9:03 AM, Peter Firmstone wrote:
> Currently the trunk branch is a stable branch, it is not for 
> development code, let's make it so we can develop in trunk.  The vote 
> concludes in two weeks.
>
> +1 Peter.
>
> Rationale:
>
> The project needs to migrate from SVN to GIT.
>
> The trunk branch is the GIT branch, currently it's only read only but 
> we can make it a live writable git repository simply with an INFRA 
> JIRA ticket.
>
> https://github.com/apache/river
>
> If we allow the trunk branch to become a development branch, then we 
> can move the current modular develpment branch into trunk, and migrate 
> other components not currently in the trunk branch like the ldj-tests, 
> surrogate and other bits and pieces, which are also in a development 
> state not ready for release.  Note that these should probably go under 
> their own directory in trunk.
>
> Doing this will preserve the commit history of Apache River.
>
> Are there any git experts on the list?
>
> If this is not the right way to go about the migration to git, please 
> give us your thoughts?
>
> Regards,
>
> Peter.
>