River people, we need one more person who's willing to review River's
latest release.
Any volunteers?
Regards,
Peter.
; acceptable test results for the particular revision, then I'll tag the
> release and generate the release packages, which we can vote on.
>
> I'd kind of like to complete this process by the end of the month.
>
> Cheers,
>
> Greg.
>
> On Thu, 2013-03-28 at 15:14,
On Apr 22, 2013, at 848AM, Greg Trasuk wrote:
>
> Hi all:
>
> I've been testing the 2.2 branch locally in a few environments, and I
> haven't seen anything that looks like anything but local configuration
> issues. So I'd like to move forward with the release process (steps
> will be described
icular revision, then I'll tag the
release and generate the release packages, which we can vote on.
I'd kind of like to complete this process by the end of the month.
Cheers,
Greg.
On Thu, 2013-03-28 at 15:14, Dennis Reedy wrote:
> Hi,
>
> Was wondering how we are doing with get
On Apr 8, 2013, at 913AM, Mark Brouwer wrote:
> On 4/7/13 4:25 AM, Greg Trasuk wrote:
>>
>>
>> The "2.2" branch is very clean. It starts from release in 2011. Since
>> then, Dennis applied RIVER-417, added poms for listing at Maven Central,
>> and applied the Levels fix. I've applied RIVER-14
On 4/7/13 4:25 AM, Greg Trasuk wrote:
The "2.2" branch is very clean. It starts from release in 2011. Since
then, Dennis applied RIVER-417, added poms for listing at Maven Central,
and applied the Levels fix. I've applied RIVER-149, and that's it.
Probably to Dennis. I noticed that what wa
The "2.2" branch is very clean. It starts from release in 2011. Since then,
Dennis applied RIVER-417, added poms for listing at Maven Central, and applied
the Levels fix. I've applied RIVER-149, and that's it.
A few days ago, I set out to see what else from the trunk should be rolled in
for
Add to the "Things we need to avoid" section:
+ Conflation of versioning tool issues with dev policy
;-)
Greg.
On Sun, 2013-04-07 at 00:08, Jeff Ramsdale wrote:
> At the risk of de-railing the conversation, is there an option to move to
> git for Apache Foundation projects such as River? I was
I'm of the opinion that this situation has occurred because of policy
decisions by various developers in respect of what development and how much
to do where. I don't think the current tooling has anything to do with
those decisions nor do I believe git would've led to a different set of
decisions.
The "situation" would still have occurred, the release process was
delayed by synchronization bugs, without which the release would have
been much simpler with fewer changes. Of course the code is actually
much better now, so it's not a bad situation, we just need to make sure
testing is very
At the risk of de-railing the conversation, is there an option to move to
git for Apache Foundation projects such as River? I was long a big
proponent of SVN but I'm now thoroughly converted and can't help but think
this situation wouldn't have occurred if git were in use. (Yes, it's
possible to do
The "2.2" branch is very clean. It starts from release in 2011. Since
then, Dennis applied RIVER-417, added poms for listing at Maven Central,
and applied the Levels fix. I've applied RIVER-149, and that's it.
A few days ago, I set out to see what else from the trunk should be
rolled in for a
Just to clarify:
Dennis & Greg are using the 2.2.0 branch from last release to fix Levels
and release 2.2.1
trunk started failing tests after some unrelated changes exposed
synchronization errors in the qa tests, since then
skunk/qa-refactoring is being used to fix synchronization issues befo
On 6 April 2013 14:44, Dennis Reedy wrote:
>
> On Apr 6, 2013, at 532AM, Dan Creswell wrote:
>
> > Right so we're into brutal tradeoffs aren't we?
> >
> > It's beginning to smell like none of the available branches are suitable
> > for doing releases from. So we need a branch that is.
>
> AFAIK w
On Apr 6, 2013, at 532AM, Dan Creswell wrote:
> Right so we're into brutal tradeoffs aren't we?
>
> It's beginning to smell like none of the available branches are suitable
> for doing releases from. So we need a branch that is.
AFAIK we are going to be releasing 2.2.1 from the 2.2 branch. Once
I feel like strangling the phone email client about now ;)
--- Begin Message ---
Ignore this message, my mail client sent it days late.
- Original message -
> Not a good idea, the qa-refactoring branch was created recently to address the
> concurrency bugs in trunk.
>
> - Original mess
Right so we're into brutal tradeoffs aren't we?
It's beginning to smell like none of the available branches are suitable
for doing releases from. So we need a branch that is.
i.e. We shouldn't just pick a branch we have, we should get one sorted and
right now.
What are our chances of pulling jus
We created a "qa-refactoring" branch for concurrency work
On 3 April 2013 22:10, Peter wrote:
> Not a good idea, the qa-refactoring branch was created recently to address
> the concurrency bugs in trunk.
>
> - Original message -
> >
> > On Apr 2, 2013, at 750AM, Peter Firmsto
Not a good idea, the qa-refactoring branch was created recently to address the
concurrency bugs in trunk.
- Original message -
>
> On Apr 2, 2013, at 750AM, Peter Firmstone wrote:
>
> > On 2/04/2013 7:51 PM, Dennis Reedy wrote:
> > > On Apr 2, 2013, at 338AM, Peter Firmstone wrote:
> > >
On Apr 3, 2013, at 120PM, Greg Trasuk wrote:
>
> On Wed, 2013-04-03 at 12:12, Dennis Reedy wrote:
>> On Apr 3, 2013, at 1115AM, Greg Trasuk wrote:
>>
>>>
>>> Did we have a branching policy discussion?
>>
>> I was looking here: http://river.apache.org/development-process.html (scroll
>> dow
On Wed, 2013-04-03 at 12:12, Dennis Reedy wrote:
> On Apr 3, 2013, at 1115AM, Greg Trasuk wrote:
>
> >
> > Did we have a branching policy discussion?
>
> I was looking here: http://river.apache.org/development-process.html (scroll
> down to "Branching Policy")
>
Ahh... That makes sense.
>
On Apr 3, 2013, at 1115AM, Greg Trasuk wrote:
>
> Did we have a branching policy discussion?
I was looking here: http://river.apache.org/development-process.html (scroll
down to "Branching Policy")
> I recall we decided not to
> do too much in the trunk. In any case, I think your suggestio
Did we have a branching policy discussion? I recall we decided not to
do too much in the trunk. In any case, I think your suggestion works,
barring any other opinions. I was thinking of creating a "2.2.1" branch
first, and then applying patches to that, but assuming there wasn't
anything big do
On Apr 3, 2013, at 1030AM, Greg Trasuk wrote:
> Hi Dennis:
>
> I think the suggestion was that we do a release branched off the 2.2.0
> release with a bare set of patches moved over - primarily the Logging
> fix and I think there was a change to one of the JRMP context classes
> that I needed fo
Hi Dennis:
I think the suggestion was that we do a release branched off the 2.2.0
release with a bare set of patches moved over - primarily the Logging
fix and I think there was a change to one of the JRMP context classes
that I needed for the Surrogate container. And then a release from the
qa_r
On Apr 2, 2013, at 750AM, Peter Firmstone wrote:
> On 2/04/2013 7:51 PM, Dennis Reedy wrote:
>> On Apr 2, 2013, at 338AM, Peter Firmstone wrote:
>>
>>> The formatting didn't work out, I'll create a Jira issue to discuss.
>>>
>>> Patricia's done a great job detailing the dependencies and issues
Dan Creswell wrote:
Thanks for that, appreciate it.
Couple of questions to clarify...
On 1 April 2013 12:13, Peter Firmstone wrote:
Shown below is both a passing test result and a failing one, logging =
FINEST.
Lease.FOREVER is actually set to 60,000.
I take it you mean that the
Thanks for that, appreciate it.
Couple of questions to clarify...
On 1 April 2013 12:13, Peter Firmstone wrote:
> Shown below is both a passing test result and a failing one, logging =
> FINEST.
>
> Lease.FOREVER is actually set to 60,000.
>
>
I take it you mean that the test's own notion of f
gt; > > Can you update the poms in skunk/qa-refactoring? I've included the
> logging fix.
> > >
> > > Regards,
> > >
> > > Peter.
> > >
> > > - Original message -
> > >
> > >> On Mar 28, 2013, at
;
> > Peter.
> >
> > - Original message -
> >
> >> On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
> >>
> >>
> >>> Dennis Reedy wrote:
> >>>
> >>>> Hi,
> >>>>
> >>
On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
Dennis Reedy wrote:
Hi,
Was wondering how we are doing with getting the next release out the door?
I'd like to suggest that we move on this as soon as possible If there are
issues that do come up with the release, we can alway
skunk/qa-refactoring? I've included the logging
fix.
Regards,
Peter.
- Original message -
>
> On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
>
> > Dennis Reedy wrote:
> > > Hi,
> > >
> > > Was wondering how we are doing with getting the
On Mar 28, 2013, at 631PM, Peter Firmstone wrote:
> Dennis Reedy wrote:
>> Hi,
>>
>> Was wondering how we are doing with getting the next release out the door?
>> I'd like to suggest that we move on this as soon as possible If there are
>> issues th
Dennis Reedy wrote:
Hi,
Was wondering how we are doing with getting the next release out the door? I'd
like to suggest that we move on this as soon as possible If there are issues
that do come up with the release, we can always release again.
Regards
Dennis
We can safely ignor
Agreed, particularly if the JDK 7 issue has been resolved, it'd be good to
get a release out there.
On Thu, Mar 28, 2013 at 7:14 PM, Dennis Reedy wrote:
> Hi,
>
> Was wondering how we are doing with getting the next release out the door?
> I'd like to suggest that we m
Hi,
Was wondering how we are doing with getting the next release out the door? I'd
like to suggest that we move on this as soon as possible If there are issues
that do come up with the release, we can always release again.
Regards
Dennis
Simon IJskes - QCG wrote:
On 01-11-12 14:35, Gerard Fulton wrote:
Sounds like the tests might need to be refactored.
Indeed. Or a revert of the patches causing the tests to fail.
Gr. Simon
Er, no, the URI patches aren't causing the tests to fail, the tests are
configured with unsupported
On 01-11-12 14:35, Gerard Fulton wrote:
Sounds like the tests might need to be refactored.
Indeed. Or a revert of the patches causing the tests to fail.
Gr. Simon
Sounds like the tests might need to be refactored.
On Thu, Nov 1, 2012 at 4:09 AM, Peter Firmstone wrote:
> I've noticed some new classes in the net.jini namespace, we need to move
> them to org.apache.river prior to release please, unless there is a good
> reason they should be there.
>
> Regard
I've noticed some new classes in the net.jini namespace, we need to move
them to org.apache.river prior to release please, unless there is a good
reason they should be there.
Regards,
Peter.
Peter Firmstone wrote:
Simon IJskes - QCG wrote:
On 28-10-12 15:47, Simon IJskes - QCG wrote:
On 28
Simon IJskes - QCG wrote:
On 28-10-12 15:47, Simon IJskes - QCG wrote:
On 28-10-12 15:45, Simon IJskes - QCG wrote:
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we
were
talking about gearing up for a release. Is there any reason why we
On 28-10-12 15:47, Simon IJskes - QCG wrote:
On 28-10-12 15:45, Simon IJskes - QCG wrote:
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we
were
talking about gearing up for a release. Is there any reason why we
can't
cut one now-ish?
no
On 28-10-12 15:45, Simon IJskes - QCG wrote:
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we were
talking about gearing up for a release. Is there any reason why we can't
cut one now-ish?
none. go for it!
Although, what do we do with
On 28-10-12 15:43, Tom Hobbs wrote:
Can someone refresh my memory, please? I recall a few months ago we were
talking about gearing up for a release. Is there any reason why we can't
cut one now-ish?
none. go for it!
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Cons
Can someone refresh my memory, please? I recall a few months ago we were
talking about gearing up for a release. Is there any reason why we can't
cut one now-ish?
Cheers,
Tom
Tom Hobbs wrote:
I'm not going to be able to finish my stuff and test it well enough to
get it into the next release.
Peter; are you happy with your commits and merging?
Almost, I've got to remove some things that are preventing compillation on Java 7.
Are we ready to
start cut
I'm not going to be able to finish my stuff and test it well enough to
get it into the next release.
Peter; are you happy with your commits and merging? Are we ready to
start cutting a new release yet?
Does anyone else have any additional code etc they want rolled into
the next release?
C
No, that's great. Let's wait on your test for that and then put it to
the vote.
Is anyone else working on anything specific for this release?
On Sun, Apr 10, 2011 at 9:23 PM, Patricia Shanahan wrote:
> I've reviewed the proposed patch for
> https://issues.apache.org/jira/browse/RIVER-395, and I
I've reviewed the proposed patch for
https://issues.apache.org/jira/browse/RIVER-395, and I think it should
be incorporated in the release. I'm working on a QA test for it, but
could check it in untested if you like.
Patricia
On 4/10/2011 1:09 PM, Tom Hobbs wrote:
Hi guys,
So including the
Hi guys,
So including the SPARC issue, are we ready to cut and vote on a new release?
Personally, I think it might be worth starting the vote now anyway.
If people don't want to release because of the SPARC thing or whatever
other reason they can always vote "-1"...
Peter and Sim, am I right in
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 Solar
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
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 ha
Not really the constructive dialog I was after...
On 1 April 2011 20:27, 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
>
Uh huh - what I can't understand is your logic for
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
wa
Dan Creswell wrote:
I think there are some other things we might consider:
(1) Do the tests in question always fail and only on SPARC?
Yes and only on the Java 6 JVM. The way security policy's are loaded
changed in Java 6. In reality a SecurityManager must be loaded at
startup with a po
I think there are some other things we might consider:
(1) Do the tests in question always fail and only on SPARC?
(2) Do the tests in question contain any SPARC specific code?
(3) Does the code being tested contain any SPARC specific code?
(4) How many cores are available on the SPARC's in que
What is the definition of "new"? Remember we added a lot of QA tests
that were not being run previously, so for most QA tests we do not know
whether they would have passed on an earlier release.
If we can define "new" as being since some specific subversion
check-out, we can build that on a SP
bit stricter: does anyone care enough to provide a
dev env *and* fix bugs :)
Fwiw, +1 on releasing with a known bug...
Sent from my HTC
- Reply message -
From: "Patricia Shanahan"
To: "dev@river.apache.org"
Subject: Remaining Work For Next Release
Date: Fri, Apr 1, 20
I would pose it even a bit stricter: does anyone care enough to provide a dev
env *and* fix bugs :)
Fwiw, +1 on releasing with a known bug...
Sent from my HTC
- Reply message -
From: "Patricia Shanahan"
To: "dev@river.apache.org"
Subject: Remaining Work For Ne
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
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
work
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
> 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
On 3/31/2011 5:41 PM, Niclas Hedhman wrote:
On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt 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
Ass
On Wed, Mar 30, 2011 at 5:48 AM, Jason Pratt 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 relat
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 wrote:
> Is that a newly introduced failure? I'm wo
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?
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
anythi
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
70 matches
Mail list logo
