river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Remaining Work For Next Release
Date Sat, 02 Apr 2011 04:47:56 GMT
It's worth noting that if a customer wants to deploy River on sparc, it 
will be relatively easy for them to do so, they'll be able to take up 
the baton, build and run the tests.

Maintaining a sparc development computer takes time and resources, you 
need a license and support contract for Solaris, hardware is expensive 
and 3rd party vendors non existent or drying up, you can't buy new sparc 
workstations either.  I've been waiting 3 years for Sun/Oracle to 
realise that workstations are an essential, albeit small market, surely 
they could have put an M3000 inside a tower case with 3D ATI graphics 
support by now.  In fact if they did that, they'd be able to sell Sparc 
Visualisation servers too.  All the other platforms you've mentioned are 
readily available. 

We don't test on IBM's Power or HP's Itanium architectures, these are 
Sparc's competitors.

I think we can get a better bang for buck, testing on other JVM's, like 
Apache Harmony, OpenJDK, JRockit and IBM J9 by eliminating our 
dependence on proprietary implementation details of Sun's JVM, but we're 
not there yet.

River's currently in a refactoring phase, our goal is to make 
development more efficient so we can ensure long term survival.  Because 
we're all volunteer developers, we need to make it possible to have 
smaller develop/test cycles.  We're all very passionate, from many 
backgrounds and countries.  We don't always agree on everything and in 
fact have more in common even when we do disagree, what matters is that 
we respect each others views, if you feel passionate enough about 
something, jump in and join in the fun.

Peter.


Peter Firmstone wrote:
> Perhaps you might be interested in helping us fix some bugs or 
> checking the release documentation?
>
> We're all just volunteers here, I've made attempts to identify the 
> source of the bug and lack the time needed to figure it out.  Patricia 
> has offered to help. Feel free to jump in and get your hands dirty.  
> If someone does have time to nut this one out, send me your public ssh 
> key & I'll set you up a user account.
>
> Cheers,
>
> Peter.
>
> Jason Pratt wrote:
>> i am stating that the first "graduated" release should work for everyone
>> period. after that if you want to release with known bugs and reduce/not
>> support sparc or whatever other platform you in your infinite wisdom 
>> deem
>> irrelevant , great. river should have one release it can point at for 
>> anyone
>> wanting to try/use it.
>>
>> regarding supporting systems, if ubuntu, amd, redhat, intel, apple, etc.
>> don't send you equipment and software to test on, are you going to drop
>> support for them as well? doesn't apache have these things 
>> internally? have
>> you asked?
>>
>> you can be as antagonistic as you like, i deal with children everyday 
>> ;-)
>>
>>
>> On Fri, Apr 1, 2011 at 9:46 PM, Dan Creswell <dan.creswell@gmail.com> 
>> wrote:
>>
>>  
>>> Why should it be valid for everyone?
>>>
>>> So far the conversation has mostly amounted to "save the SPARC user" 
>>> at any
>>> cost and that cost includes "penalise all other users".
>>>
>>> Is that latter cost something we think we should be asserting? And 
>>> for how
>>> long?
>>>
>>> Further, if those using SPARC can't lend us a box to test on, how 
>>> serious
>>> are they about their investment in River? Simply and brutally, 
>>> they're not
>>> supporting us (an opensource co-operative effort), why would we in turn
>>> support them?
>>>
>>> Last up, if we are to support these SPARC users and they won't 
>>> provide the
>>> kit, we have to obtain it and maintain it etc - how are we doing 
>>> with that?
>>> How well can we do that going forward?
>>>
>>> My point overall then is that there's a balance and as yet, I don't 
>>> see a
>>> proper discussion about that balance just what would be ideal in a 
>>> perfect
>>> world.
>>>
>>> Yeah, I am being a little antagonistic,
>>>
>>> Dan.
>>>
>>>
>>> On 1 April 2011 09:18, Jason Pratt <jpratt3000@gmail.com> wrote:
>>>
>>>    
>>>> sparc was a key architecture when jini was being promoted, maybe 
>>>> not so
>>>> much
>>>> now. however, at least for a graduation release it should be valid for
>>>> everyone sparc included. afterwards if justified it can be phased out.
>>>>
>>>> antagonism aside, for its first release let give the masses something
>>>>       
>>> that
>>>    
>>>> works...
>>>>
>>>> jason
>>>>
>>>> On Fri, Apr 1, 2011 at 1:51 PM, Patricia Shanahan <pats@acm.org> 
>>>> wrote:
>>>>
>>>>      
>>>>> On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
>>>>>
>>>>>        
>>>>>> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jpratt3000@gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>          
>>>>>>> please don't release anything with failures. i've been a big

>>>>>>> fan/user
>>>>>>>             
>>>> of
>>>>      
>>>>>>> jini since it was released. now that it is alive again via river,
a
>>>>>>>             
>>>> good
>>>>      
>>>>>>> release history will be key to success/survival
>>>>>>>
>>>>>>>             
>>>>>> Assume for a second that the failure is related to the SPARC JVM
>>>>>> implementation; For how long do you intend us to hold off a 
>>>>>> release to
>>>>>> the other 99.9654% of the users, searching for a compatible way to
>>>>>> work around the problem?
>>>>>>
>>>>>> Sometimes, "known bugs" are just that. The "unknown bugs" is in most
>>>>>> cases a longer list, and should that also hold off a release 
>>>>>> until we
>>>>>> find and correct them?
>>>>>>
>>>>>> I hope I don't come across as too antagonistic... ;-)  ... just want
>>>>>> to provide some perspective.
>>>>>>
>>>>>>           
>>>>> Here's a key question for the future. Are there users that need River
>>>>>         
>>> on
>>>    
>>>>> SPARC? Do we go on supporting it? Does anyone care enough to make a
>>>>> SPARC development environment available?
>>>>>
>>>>> Patricia
>>>>>
>>>>>         
>>
>>   
>
>


Mime
View raw message