river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Costers <jonathan.cost...@googlemail.com>
Subject Re: Modular Build, Java 5, (Was: Re: Unexpected Test Results)
Date Wed, 15 Sep 2010 10:16:55 GMT
Please do. Thanks!

2010/9/15 Peter Firmstone <jini@zeus.net.au>

> Jonathan Costers wrote:
>
>> Make sure we have the original River distribution working OK (i.e. get all
>> test passing): +1
>>
>>
> I've got skunk/pepe passing alright, I've removed the problematic
> experimental code.  Would you like me to remove the experimental classes
> from trunk?
>
> Actually there is one test in jtreg we need to look into, but I figure we
> can wait for the qa tests to be right first.
>
>  Worry about issues that are not even relevant if we don't have a working
>> distributrion: -1
>>
>>
>> 2010/9/15 Sim IJskes - QCG <sim@qcg.nl>
>>
>>
>>
>>> On 09/15/2010 01:56 AM, Peter Firmstone wrote:
>>>
>>>
>>>
>>>> I don't want to have to answer user queries like: "I've set up a new
>>>> djinn group for my new Apache River nodes, but my existing Jini nodes
>>>> can't discover the new group. The new nodes are using my existing
>>>> programs and they work among themselves, but the new Registrars aren't
>>>> working with my older nodes. The new nodes services work with my old
>>>> clients only if they register with existing Registrars. Reggie seems
>>>> broken in Apache River 2.2.0?"
>>>>
>>>>
>>>>
>>> Why don't we just worry about creating a working River, and let the
>>> compatibility issues be solved by the market? Most deployments are done
>>> within the boundaries of a single organization. They should have done
>>> this
>>> incompatible upgrade multiple times, it not something that is unique to a
>>> river upgrade. Most bigger organizations will have their own
>>> software-library, and establish their own software baselines by cloning
>>> our
>>> vcs.
>>>
>>> Keep compatible: -1
>>>
>>> Gr. Sim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

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