I have a constant tension between two ways of thinking.
As a programmer, looking only at the best way to fix bugs and make the
software faster and more reliable, I sorely miss JDK 1.5 and 1.6
features, especially java.util.concurrent etc., which makes concurrent
programming much cleaner.
On the other hand, I've interacted with people managing large networks,
and software developers who distribute their products to organizations
with large networks. Those two audiences tend to be extremely
conservative. Supporting an infrastructure software release is a big
deal, with enormous testing costs. Moving to a new release, especially
if it has to be done simultaneously on multiple systems, is a major
project, with months of planning and preparation.
I am having a lot of trouble even deciding on my own position on which
releases to support.
I would like to start a sub-project, perhaps as a Wiki page, on writing
a migration guide. If we can't come up with a good plan for using our
release strategy in a large network, we need to rethink the release
strategy. If we can, we should document it and ask the user mailing list
to review it.
Patricia
Gregg Wonderly wrote:
River's primary feature is network based communications and long running
services with "compatibility" as a "key behavior" that makes things
continue to work. The original RMI implementation was unchangable from
the outside. The addition of JERI made "communication protocols" a
deployment decision. However, discovery still has to be "compatible"
and we need to make real effort on "namespace" compatibility after the
"switch to org.apache". People will be forking river right and left and
contributing nothing if we don't try very hard to "worry about
compatibility" and "make it happen when at all possible".
These are not desktop applications that get replaced by individual users
randomly so they can take advantage of upgrades when they want. This is
about network based services with broadcast client deployment via
ServiceUI, much like a web page is. Since river is "infrastructure" and
not "the service", we need to help users experience minimum impact on
their deployments so that they can easily adopt new releases of river
that include bug fixes for example. The work that Patricia is doing to
shake out transaction manager misbehaviors and probably leasing issues
too, is the kind of "fixes" that we want everyone to be able to "accept"
with "trivial compatibility issues".
Gregg Wonderly
On 11/24/2010 8:40 AM, Sim IJskes - QCG wrote:
On 11/24/2010 03:11 PM, Patricia Shanahan wrote:
If we had started a formal vote, the qualification might indicate that
we had not yet done enough discussing. I suggest we continue discussing
a little longer, and then call a vote. We will probably be able to reach
a consensus proposal that will get a lot of definite positive votes.
I'm aware off the differences between a formal and a informal vote. A
informal
vote however is a clear indication how one will vote when a formal
vote is called.
I can understand you want to go throught due process in determining
what we are
going to do. But my personal impression from the mailing list
archives, is that
the river project is completely gridlocked in subtleties. I'm not
saying that
something agreed has a lifetime of infinity, but we have to start
somewhere.
That means quick, decisive action, while keeping our options open.
Suppose we declare to support 1.4, 1.5, 1.6 and CDC. How do we
validate this? I
don't see us building a compatibity verification on short notice.
If you want to go for river worlddomination, by keeping everything
compatible,
you should bring a large suitcase of money. Then you can checkout an
older
revision from the repo and build something with the horde of
programmers you are
hiring.
River has to grow from spurts from contributors, we are not going to
win a race
by creating a swamp. I strongly believe that the current failure of
river is
because of this longwinding process. We are not going to attract more
young
eager bright committers if we keep on discussing the future of river
or the
subtleties of compatibility.
Gr. Sim
