You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <tv...@googlemail.com> on 2011/03/29 23:25:33 UTC
Remaining Work For Next Release
Hi guys,
Everything's been a bit quiet recently. I was just wonder what (if
anything) is left to do for our first post-graduation release.
Cheers,
Tom
Re: Remaining Work For Next Release
Posted by Tom Hobbs <tv...@googlemail.com>.
Firstly, I think if this is a new bug then we shouldn't do a release. If
it's a newly discovered bug or a well known one then I think that it's
probably okay to.
I know of at least one corporate user who is still on Jini 2.1 and who I'm
encouraging to move to River once the build is made modular (or not) and the
namespace changes are complete. They use it on Sparc machines, so it would
be important to them. I can ask if they'd be prepared to let us borrow one
of them, but I wouldn't hold out much hope that they'd be able to.
Thanks for your kind offer, Greg. I know that Peter has made a similar
offer, but I think he's snowed under with lots of other stuff at the moment.
So besides this Sparc bug, is all the rest of the work complete for the
release?
It's good to start seeing some noise on the list again!
On 1 Apr 2011 03:54, "Greg Trasuk" <tr...@stratuscom.com> wrote:
>
>> 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
>
> I've just acquired a pair of Sun Ultra 5 workstations, but haven't had a
> chance to set them up or see if they work. When I do, I'll be happy to
> make a remote environment available for River development. Might be a
> while before I get them up and running though.
>
> Going out on a limb, I suspect that there are users out there for Sparc
> systems, so perhaps one of them might be quicker off the mark to allow
> development...
>
> Cheers,
>
> Greg.
>
>
Re: Remaining Work For Next Release
Posted by Greg Trasuk <tr...@stratuscom.com>.
> 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
I've just acquired a pair of Sun Ultra 5 workstations, but haven't had a
chance to set them up or see if they work. When I do, I'll be happy to
make a remote environment available for River development. Might be a
while before I get them up and running though.
Going out on a limb, I suspect that there are users out there for Sparc
systems, so perhaps one of them might be quicker off the mark to allow
development...
Cheers,
Greg.
Re: Remaining Work For Next Release
Posted by Dan Creswell <da...@gmail.com>.
Not really the constructive dialog I was after...
On 1 April 2011 20:27, Jason Pratt <jp...@gmail.com> 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
>
Uh huh - what I can't understand is your logic for why that must be the
case?
> support sparc or whatever other platform you in your infinite wisdom deem
>
My infinite wisdom? I didn't say I was wise or a know it all.
> irrelevant , great. river should have one release it can point at for
> anyone
> wanting to try/use it.
>
Why? What would that mean? What does that achieve?
>
> 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?
>
>
I was asking questions to encourage discussion of a broader point, not
stating a definitive position:
" I don't see a proper discussion about that balance just...."
> you can be as antagonistic as you like, i deal with children everyday ;-)
>
>
> On Fri, Apr 1, 2011 at 9:46 PM, Dan Creswell <da...@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 <jp...@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 <pa...@acm.org>
> wrote:
> > >
> > > > On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
> > > >
> > > >> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
> > > >
> > >
> >
>
Re: Remaining Work For Next Release
Posted by Patricia Shanahan <pa...@acm.org>.
On 4/1/2011 12:27 PM, 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.
I don't know whether SPARC is irrelevant or not - that is one of the
questions we are trying to discuss. For admittedly emotional reasons, I
hope it continues to be relevant. I worked for many years designing
SPARC servers for FPS, Cray Research, and Sun Microsystems.
Maybe we'll find the SPARC failure quickly, and it will have a simple
fix. In that case, I'm sure we should include the fix in the next release.
Suppose it does not work out that way. Then we face a trade-off. How
long should we hold up the next release pending a fix for a SPARC-only
problem? Remember that means holding back fixes for bugs that affect all
systems, SPARC included.
You seem to be saying that you think there is no limit on how long we
should hold the release. Is that correct? If so, why?
Patricia
Re: Remaining Work For Next Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 <da...@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 <jp...@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 <pa...@acm.org>
>>>> wrote:
>>>>
>>>>
>>>>> On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
>>>>>
>>>>>
>>>>>> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
>>>>>
>>>>>
>>
>>
>
>
Re: Remaining Work For Next Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 <da...@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 <jp...@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 <pa...@acm.org> wrote:
>>>
>>>
>>>> On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
>>>>
>>>>
>>>>> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
>>>>
>>>>
>
>
Re: Remaining Work For Next Release
Posted by Jason Pratt <jp...@gmail.com>.
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 <da...@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 <jp...@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 <pa...@acm.org> wrote:
> >
> > > On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
> > >
> > >> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
> > >
> >
>
Re: Remaining Work For Next Release
Posted by Dan Creswell <da...@gmail.com>.
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 <jp...@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 <pa...@acm.org> wrote:
>
> > On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
> >
> >> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
> >
>
Re: Remaining Work For Next Release
Posted by Jason Pratt <jp...@gmail.com>.
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 <pa...@acm.org> wrote:
> On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
>
>> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
>
Re: Remaining Work For Next Release
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
> On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt<jp...@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
Re: Remaining Work For Next Release
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt <jp...@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.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
Re: Remaining Work For Next Release
Posted by Jason Pratt <jp...@gmail.com>.
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
jason
On Wed, Mar 30, 2011 at 10:34 AM, Tom Hobbs <tv...@googlemail.com> wrote:
> Is that a newly introduced failure? I'm wondering if we can do a release
> anyway.
>
> I vaguely recall Peter and Sim talking about the steps required to do a
> release a while back. Sim, did yoh get anywhere with it?
>
Re: Remaining Work For Next Release
Posted by Tom Hobbs <tv...@googlemail.com>.
Is that a newly introduced failure? I'm wondering if we can do a release
anyway.
I vaguely recall Peter and Sim talking about the steps required to do a
release a while back. Sim, did yoh get anywhere with it?
Re: Remaining Work For Next Release
Posted by Patricia Shanahan <pa...@acm.org>.
We have a SPARC-only QA failure that I'm willing to take a look at if
Peter sets up an account for me. Otherwise, I'm looking ahead to work on
fault tolerance.
Patricia
On 3/29/2011 2:25 PM, Tom Hobbs wrote:
> Hi guys,
>
> Everything's been a bit quiet recently. I was just wonder what (if
> anything) is left to do for our first post-graduation release.
>
> Cheers,
>
> Tom
>