river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Next steps after 2.2.1 release
Date Mon, 08 Apr 2013 08:53:02 GMT
So....

On 7 April 2013 22:16, Peter <jini@zeus.net.au> wrote:

> +1 for 2.2.1 release.
> +1 to investigate modular build options.
>
> -1 for broad brush proposal based on incorrect assumptions.
>
>
> I'm concerned people are jumping to conclusions and making incorrect
> assumptions, the understanding of the current build is clearly lacking:
>
>
And where would one find information on "the current build"?

Heck, define "the current build". Which branch would that be?

Are you referring to something sitting in skunk? As opposed to trunk which
to quote what we have publicly documented is "mainline development"

http://river.apache.org/development-process.html

My two cents, the reason it's "clearly lacking" is because it clearly
"isn't shared knowledge". And why is that?

1. The qa suite can be run against any other build by changing the
> RIVER_HOME property.  It's already a separate build, it's not coupled.  It
> is where it is for convenience and ease of use for new developers.
> 2.  Windows passes all tests with trunk and qa-refactoring.  We have
> RFC3986 compliant URI paths that can handle spaces and illegal characters.
>  Yes these builds are more jini standards compliant than the so called
> clean 2.2 branch.
> 3.  The quality of the code in trunk and qa-refactoring is far superior to
> the 2.2 branch.
> 4.  Branching a new trunk off 2.2, because it's "clean" is insufficient
> justification and discards three years of hard work.
> 5.  The integration tests cannot be replaced by junit, all test frameworks
> in use are of equal importance.
> 6.  I have not seen one question regarding the code, this has been
> developed in collaboration, with multiple discussions on trunk and with
> standards compliance testing over the last 3 years.
>
>
"In collaboration"? Sorry, I'm going to beg to differ. There has been
discussion for sure but agreement that all the bits and pieces being worked
on should be worked on or which branch to put them in or how far to go
before making a release or what should be done to help out the community?
No. Don't think so.

Just look here and see: http://river.apache.org/roadmap.html


> Furthermore:
>
> I reiterate; I am confident the latest code is superior to 2.2 and is API
> compatible.
>

Except you still have at least one outstanding likely concurrency problem
and the nature of these means we can never be sure they're all gone.

You can claim superiority in your own opinion, which is lovely but it isn't
collaborative nor is it hard proven fact. The changes you've made are
important to you, are they for everyone else? Maybe that doesn't matter?


>
> My next task is to refactor or remove TaskManager.  Once this is done I'll
> release 2.3.0
>

Why? Because we have as yet unproven assumptions that it *might* be the
cause of problems in 2.3.0?

Evidence?

And, whilst it might be your next task, is it the community's?


>
> I refuse to participate in a new trunk branched off 2.2, it is doomed to
> fail, discarding 3 years of synchronization fixes, concurrency improvements
> as well as fixes for fundamental platform issues like over reliance on DNS
> is engaging in an act of project vandalism.
>

Over-reliance on DNS is not a fundamental platform issue and no one is
talking about discarding. People *are* talking about a more gradual change
process and multiple releases. Something like continuous integration and
iterative, micro-releases which is generally agreed to be a "good thing".


>
> Developers are free to maintain a 2.2 branch, I'm not against that.  In
> fact it would allow a transition period.
>
> People need to think very carefully before making rash decisions, remember
> your actions are on public display, do more research, choose your next move
> wisely.
>

Yes sir, they are indeed, yours too.

There are a bunch of you with good intentions, equally you all, rather
obviously, have your own individual agendas and they are showing through.
And you aren't discussing them openly or indeed acting much like a
community because of it.

The thing of it is, if you got your individual agendas organised and onto a
roadmap you'd have a pretty solid future and some great prospects for the
codebase. Alas, you're all binning it off. This has been a problem for
River way back in its Jini days and we're no further forward. Greg T (oh
wait, what's his role again? You elected him remember) is attempting to get
that discussion under way yet again. Looks like it's doomed yet again.

Frankly, it makes me sick because it's such a criminal waste of talent and
code. Sort it for heavens sake....



>
> Regards,
>
> Peter Firmstone.
>
> ----- Original message -----
> >
> > On Sun, 2013-04-07 at 10:18, Dennis Reedy wrote:
> > > On Apr 6, 2013, at 1026PM, Greg Trasuk wrote:
> > > >
> > > > Proposal
> > > > ------------
> > > >
> > > > 1 - Release version 2.2.1 from the 2.2 branch.
> > >
> > > +1 for this, we really need to get this done, and get this done before
> > > the end of the month.
> >
> > Agreed.  I was sincerely hoping for this last month.
> >
> > >
> > >
> > > > 2 - Create a separate source tree for the test framework.  This
> > > could come from the "qa_refactor" branch, but the goal should be to
> > > successfully test the 2.2.1 release.  Plus it should be a no-brainer
> > > to pull it down and run it on a local machine.
> > >
> > > I would actually like to have the (at least) unit tests part of the
> > > same source tree. I can see integration tests being in a separate
> > > module, but it should not be a separate source tree. When River gets
> > > built we should automatically run unit tests. Integration testing can
> > > happen as a separate step.
> > >
> >
> > Unit tests in the main source tree are fine.  But I feel like we've
> > reached the point we're at because we don't have a clean separation
> > between the code and the integration/regression tests.  Hence I'd like
> > to make sure that there's a test package separate from the development
> > branch, so that we can have confidence that the core functionality.
> >
> > > Additionally, I also dont see why we need a "test framework" per se.
> > > Why not just use JUnit or TestNG?
> > I don't see a problem with streamlining the tests, once the integration
> > and regression tests are split out.  If we're going to develop/modify
> > tests, I want to make sure we can run them against a known-good release
> > build.  Only then can we apply them to a "probably good" release
> > candidate.  Seems to me that splitting out the acceptance testing is a
> > convenient way to allow for separate governance on the tests and core
> > functionality.
> >
> > By the way, I think a part of me just died when I used the "g-word"
> > above :-)
> >
> > >
> > > > 3 - Release 2.2.2 from the pruned jtsk tree.  Release 1.0.0 of the
> > > test framework.
> > > > 4 - Pull out the infrastructure service implementations (Reggie,
> > > Outrigger, Norm, etc) from the core into separate products.  Release
> > > 1.0.0 on each of them.  Release 2.2.3 from the pruned jtsk tree.
> > >
> > > Yes, we need to trim up project. Once 2.2.1 is released I had planned
> > > on branching and starting a modular (maven-ized) project. I really do
> > > not know what the state of trunk, qa-trunk (or any other branch) so
> > > starting with 2.2 as the baseline seems more stable to me.
> >
> > That's about where I'm coming from too.
> >
> > >
> > > Regards
> > >
> > > Dennis
> >
>
>

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