river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development
Date Wed, 22 Jan 2014 15:08:42 GMT

I understand the sentiment, but I’m uncomfortable with the number of changes that happened
without much review between releases.  Run the following commands:

svn diff https://svn.apache.org/repos/asf/river/jtsk/trunk https://svn.apache.org/repos/asf/river/jtsk/branches/2.2

svn diff https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk https://svn.apache.org/repos/asf/river/jtsk/branches/2.2

Note that much of the test code changed alongside the implementation code.    Also, if you
look at the commit history, there’s a lot of experimentation and cases where the code went
down one path and then retreated.  Unfortunately, I think trunk and qa_refactor became experimental
branches.  No problem with that, but it would be hazardous to just blindly merge them back.

I think that there are so many changes that we’re best to treat the 2.2 branch as “current”
and then integrate the new code piece-by-piece with full discussions, reviews and a fall-back



On Jan 22, 2014, at 9:30 AM, Dennis Reedy <dennis.reedy@gmail.com> wrote:

> On Jan 22, 2014, at 916AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
>> On Jan 21, 2014, at 6:57 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>>> If this proposal is supported, I'd also reccommend that trunk be reverted back
to the 2.2 River branch, with the exception of Sim's work on ClassLoading, which should be
>>> Provided there is support, change trunk to review then commit without lazy concensus.
>>> I would finish the work on qa_refactor and solve the remaining multithreaded
issues (on a longer lower pressure time schedule), the River community can then decide whether
it wants to use code from qa_refactor on an as needed basis.  I believe that the River community
will find this code a useful reference for latent multithreaded bugs.
>> I’m in favour of this approach.
> I'm not. I think trunk should contain the ongoing development of River. We have the 2.2
branch, I think 2.2 should stay there. I would like to see qa_refactor moved to trunk, have
com.sun.jini namespace changed to org.apache.river and move to 3.0.
> Regards
> Dennis

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