river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development
Date Sun, 02 Feb 2014 13:13:07 GMT
Thanks Tom,

Reviewing test failures run against the old test suite sounds like a good approach, once the
build stabilises, a goal which draws nearer with every commit.  It's important that the community
gets involved, reviews etc, so the code is of the highest possible quality.

For now, I'll just keep squashing bugs...

Regards,

Peter.

----- Original message -----
> +1
> 
> I'm in agreement with Dennis on this one.   To me it makes sense to move
> River forward with a nice big bang "miracle upgrade".   :-)   And adopting
> this stuff in as a v3.0 seems like a good idea.   I would like to see the
> results of the old test suites run against the new code and the other way
> around.   I appreciate that they're not all going to pass either which
> way, but I can see the failure reports as being good starting points to
> dive into reviewing the code changes.
> 
> I agree that this is a big risk, but it's not like there are no ways out
> or back.   Version 3.0.x can be released for bug fixes, or worst case, we
> post a message saying "Don't touch v3.0!"   Also, people can also just
> chose not to upgrade.
> 
> 
> 
> 
> On Sun, Jan 26, 2014 at 12:33 AM, Gregg Wonderly <gergg@cox.net> wrote:
> 
> > This will not be productive.   Either way you will get to the same
> > results as having qa as a basis for the future, in some form if what
> > exists now.
> > 
> > This JMM stuff related to the 1.5 changes in Java are very real and
> > very serious issues.   It should not be ignored nor suppressed as
> > something that rarely is an issue.   The removal of HashTable, Vector
> > and lots of other HappensBeforeGenerators will completely break all
> > kinds of previously functioning code. That's why stuff has
> > mysteriously broken. It wasn't compliant to begin with and used side
> > effects of other code to semi-function.
> > 
> > Gregg
> > 
> > Sent from my iPhone
> > 
> > > On Jan 22, 2014, at 9:08 AM, Greg Trasuk <trasukg@stratuscom.com>
> > > wrote:
> > > 
> > > 
> > > 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 plan.
> > > 
> > > Cheers,
> > > 
> > > Greg.
> > > 
> > > 
> > > 
> > > > 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 included.
> > > > > > 
> > > > > > 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
> > > 
> > 


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