eedy wrote:
Peter,
Recovered missing org.apache.river.test.support.* what is the status
of custard-apple artifact? This is a blocker for the release as well.
Dennis
Thanks Dennis, I'm considering uploading it to Maven, otherwise I'll
commit it to River, I wanted to make sure we're sta
On 5/09/2015 1:04 AM, Dennis Reedy wrote:
Peter,
Recovered missing org.apache.river.test.support.* what is the status of
custard-apple artifact? This is a blocker for the release as well.
Dennis
Thanks Dennis, I'm considering uploading it to Maven, otherwise I'll
commit it to River, I
Peter,
Recovered missing org.apache.river.test.support.* what is the status of
custard-apple artifact? This is a blocker for the release as well.
Dennis
> On Sep 3, 2015, at 1155PM, Peter <j...@zeus.net.au> wrote:
>
> Dennis,
>
> We're still missing the following pac
ge.
>
Here is my real point when I suggest that GroovyConfiguration might be best
separated out into a separate project. We could structure a project, discuss
it, vote on a release and have it into Maven Central by the end of next week.
So users of River could have an easy way to use a Groov
+1 on a short path to a 3.0 release. Everything else can go into a
backlog for 3.1+.
Bryan
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://m
I think that we could:
1. Release 3.0 on the shortest path consistent with appropriate QA.
2a. Refactor the project structure into modules
2b. Extend the project into interesting use case areas (IoT was discussed
recently).
2a and 2b could occur in parallel.
A release with a project modular
> On Sep 3, 2015, at 203PM, Bryan Thompson <br...@systap.com> wrote:
>
> I think that we could:
>
> 1. Release 3.0 on the shortest path consistent with appropriate QA.
> 2a. Refactor the project structure into modules
> 2b. Extend the project into interesting use ca
Spinning off a 2.2.2 modularization effort to me sounds like it could
create some confusion and undermine the 3.0 release. I'd rather focus the
modularization effort into 3.0. Modularization is a huge pain and the
payoff is long term. Rather not pay it twice.
Yes. Big ant projects with checked
> On Sep 3, 2015, at 218PM, Bryan Thompson <br...@systap.com> wrote:
>
> Spinning off a 2.2.2 modularization effort to me sounds like it could
> create some confusion and undermine the 3.0 release. I'd rather focus the
> modularization effort into 3.0. Modulari
erhaps our confusion is because I haven’t fully
> explained what I mean by “separate deliverable”. I should probably create a
> separate thread to talk about “projects and deliverables” and how they relate
> to repositories. The gist of what I’m getting at is that a “release”
> shoul
ave a strong opinion about the use of dep-libs. I don’t like it. I
don’t like it at all. We need to deal with getting jar files out of the source
release. I don’t think we have any business archiving and distributing someone
else’s artifacts, even if the license does allow it. I do know that Ap
Dennis,
We're still missing the following package from the qa test suite:
org.apache.river.test.support.*
I've added it locally and now the qa test suite is running, I'll report
back my results.
Regards,
Peter.
Initial jtreg regression test results, will look into it later:
Sorry we don't have the Bug ID's from the Sun bug database, Sun / Oracle
never donated them.
java/rmi/server/RMIClassLoader/loadProxyClasses/PreferredLoadProxyClasses.java
Failed. Execution failed: `main'
figurationFile. If others
feel strongly about this, I’ll move it into org.apache.river.config. If thats
the case, then ConfigurationFile should move as well? Otherwise lets keep it in
net.jini.config
>
> I do have a strong opinion about the use of dep-libs. I don’t like it. I
> don’
spinning stuff out of it. But as I said,
I don’t have a strong opinion.
I do have a strong opinion about the use of dep-libs. I don’t like it. I
don’t like it at all. We need to deal with getting jar files out of the source
release. I don’t think we have any business archiving and
You guys rock - thanks for all the effort involved.
Dawid Loubser
On 02/09/2015 15:01, Peter wrote:
> Thanks Dennis.
>
> On 2/09/2015 10:58 PM, Dennis Reedy wrote:
>> Peter,
>>
>> Should be all set now, just pushed the missing sources and resources.
>>
>> Dennis
>>
>>> On Sep 2, 2015, at 357AM,
If you have it handy :)
On 3/09/2015 12:43 AM, Dennis Reedy wrote:
Sooo … do you need the package rename utility?
Dennis
/jtsk/skunk/qa-refactor-namespace/trunk/
Once checked in as source, the dependency imports can be changed to use the
new namespace. I am willing to volunteer to make that code change if it
reduces your burden and moves us closer to a release. I expect that this
is just running a script over
were the one to check it in.
On 8/31/2015 6:11 AM, Bryan Thompson wrote:
Fine by me. I am pretty sure Peter already indicated approval for
this.
I
was just offering to help remove a potential blocker for the release.
+1 for publishing apple custard as a river artifact.
Bryan
Bryan Tho
hough Peter has indicated approval, from a licensing point of view it
might be best if he were the one to check it in.
On 8/31/2015 6:11 AM, Bryan Thompson wrote:
Fine by me. I am pretty sure Peter already indicated approval for this.
I
was just offering to help remove a potential blocker for the r
checked in as source, the dependency imports can be changed to use the
new namespace. I am willing to volunteer to make that code change if it
reduces your burden and moves us closer to a release. I expect that this
is just running a script over the imports to change the package names from
au.net.zeus
into a maven artifact to be release with river 3.0 and change the
dependency from the /dep-libs folder to the river artifact for
custard-apple?
Perhaps they could go into a org.apache.river.concurrent package? That
namespace does not appear to be in use at [2].
Thanks,
Bryan
[2]
https://svn.apache.org
is
> > prohibited. If you have received this communication in error, please
> notify
> > the sender by reply email and permanently delete all copies of the email
> > and its contents and attachments.
> >
> > On Mon, Aug 31, 2015 at 10:07 AM, Patricia Shanahan <p...
publish the artifact to
maven? We are pretty deep in the process of publishing out a variety of
maven artifacts. Brad (cc) might be amenable to doing this to help remove
possible blockers from a 3.0 river release.
Just fyi, we are in US eastern so the time zone difference is pretty large.
Bryan
blocker for the release.
+1 for publishing apple custard as a river artifact.
Bryan
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io
Blazegr
through River. We’re perfectly free to publish more than one
artifact under the org.apache.river.* group id. We would need to create a
subversion or git repository for it and then vote a release, the same as any
other release.
Cheers,
Greg Trasuk
> On Aug 31, 2015, at 3:37 AM, Peter
>
> On 8/31/2015 6:11 AM, Bryan Thompson wrote:
>
>> Fine by me. I am pretty sure Peter already indicated approval for this.
>> I
>> was just offering to help remove a potential blocker for the release.
>>
>> +1 for publishing apple custard as a river artifact.
Fine by me. I am pretty sure Peter already indicated approval for this. I
was just offering to help remove a potential blocker for the release.
+1 for publishing apple custard as a river artifact.
Bryan
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro
t 10:07 AM, Patricia Shanahan <p...@acm.org> wrote:
>
>> Although Peter has indicated approval, from a licensing point of view it
>> might be best if he were the one to check it in.
>>
>>
>> On 8/31/2015 6:11 AM, Bryan Thompson wrote:
>>
>&g
Peter, would you be open to having someone else publish the artifact to
maven? We are pretty deep in the process of publishing out a variety of
maven artifacts. Brad (cc) might be amenable to doing this to help remove
possible blockers from a 3.0 river release.
Just fyi, we are in US eastern
If we have a dependency on a library that’s not in Maven Central, then using
River in a Maven-based project (for example, the River Examples project) will
effectively be impossible (it can be done but is a royal nuisance for
downstream users).
As such, I’d vote against any release that has
but
is a royal nuisance for downstream users).
As such, I’d vote against any release that has a dependency on a
library that’s not in Maven Central.
If Peter’s not able to put custard-apple into Maven Central, then I
think we have no choice but to accept it as contributed code and roll
it into River
.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run the qa
test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-apple library is available
Shanahan wrote:
Which Java version(s) should be supported for release 3.0?
It would simplify testing if we only support JDK 8.
Because of changes such as the package renaming, I expect users to
need to do their own development and testing to use the new release,
so I don't see much additional burden
by duplicated
security checks.
Only custard-apple is required.
Peter.
On 10/08/2015 6:04 PM, Peter wrote:
Pat,
I don't have much time, but I'll assist you where I can.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch
to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-apple library is available on Sourceforge, it's a
Collections wrapper library that enables weak, soft and strong
Does it have a license that lets us do that?
(If you are the writer, and copy it in yourself, it would be covered by
your ICLA, just like any other code you contribute to Apache.)
On 8/12/2015 12:00 AM, Peter wrote:
...
I'm a little busy right now to consider moving custard apple. If you
It's AL2 licensed, the source is in a jar file in dep-libs, consider it
already contributed.
The library contains more code than you need, as it covers every type of
Java Collections interface, up to Java 7 (it will be updated at some
point to support Java 8 9 collections interfaces also).
Thanks, Peter.
It appears to me that we have three options for dealing with custard
apple:
1. Do not include it in the release, but include a download link in the
installation instructions.
Pro: easy for us. Con: more work for users.
2. Include a selected source subset that River
be supported for release 3.0?
It would simplify testing if we only support JDK 8.
Because of changes such as the package renaming, I expect users to need to do
their own development and testing to use the new release, so I don't see much
additional burden in switching to the current Java version
On 11/08/2015 8:33 AM, Patricia Shanahan wrote:
Which Java version(s) should be supported for release 3.0?
It would simplify testing if we only support JDK 8.
Because of changes such as the package renaming, I expect users to
need to do their own development and testing to use the new release
+1’s (binding) from Greg, Pat, and Peter
+1 (nonbinding) from Bryan.
The release vote passes. I’ve uploaded to dist and to Maven Central via
repository.apache.org http://repository.apache.org/. I’ll update the website
in a day or two when the mirrors update.
Cheers, and Thanks!
Greg
Which Java version(s) should be supported for release 3.0?
It would simplify testing if we only support JDK 8.
Because of changes such as the package renaming, I expect users to need
to do their own development and testing to use the new release, so I
don't see much additional burden
Pat,
I don't have much time, but I'll assist you where I can.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
+1 Peter.
On 10/08/2015 11:52 AM, Patricia Shanahan wrote:
+1 (binding)
On 8/7/2015 12:58 PM, Greg Trasuk wrote:
Hello all:
Please review and vote on the release of Apache River Examples v1.0
The staging repository is at:
https://repository.apache.org/content/repositories/orgapacheriver
Excellent. I am glad to see this moving forward.
Copying Brad, who heads our CI integration efforts. We have a large
refactor coming back to master on our code base, once that is stable we can
look at a refactor to the new river release package names and provide
feedback based on that.
Please
newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-apple library is available on Sourceforge, it's a
Collections wrapper library that enables weak
a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-apple library is available on Sourceforge, it's a
Collections
assist you where I can.
First things first, you'll need a Unix environment.
I'd copy Dennis newly created branch to a 3.0 release branch, then run
the qa test suite and jtreg test suite.
ant all.build
ant qa.run
cd ./qa
ant jtreg
cd ../
ant release
To answer Greg's question:
The custard-apple
Pat:
I can provide support and information for you. But I do think we need to first
sort out the dependencies question I pointed out earlier.
Cheers,
Greg Trasuk
On Aug 9, 2015, at 9:58 PM, Patricia Shanahan p...@acm.org wrote:
I am going to include the lack of a release manager for 3.0
I am going to include the lack of a release manager for 3.0 in the board
report, and assign myself an action item to fix it.
At this point I think my best bet is to appeal on the
d...@community.apache.org mailing list for a mentor who is familiar with
the release process to guide me through
In that case, I'll take on the actual release manager role, and get
going on dealing with the dependency issue.
On 8/9/2015 8:38 PM, Greg Trasuk wrote:
Pat:
I can provide support and information for you. But I do think we need to first
sort out the dependencies question I pointed out
+1. I vote to release this artifact.
On Friday, August 7, 2015, Greg Trasuk tras...@stratuscom.com wrote:
Hello all:
Please review and vote on the release of Apache River Examples v1.0
The staging repository is at:
https://repository.apache.org/content/repositories/orgapacheriver-1001
Bryan,
Are you able and willing to act as release manager for 3.0?
On 8/6/2015 11:56 AM, Bryan Thompson wrote:
Just release to encourage people to use it. +1 on release.for me.
On Aug 6, 2015 2:55 PM, Patricia Shanahan p...@acm.org wrote:
Would it be useful to tag it as a 3.0 beta release
in an
Apache project release. I am just not a good candidate for this.
Thanks,
Bryan
On Saturday, August 8, 2015, Patricia Shanahan p...@acm.org wrote:
Bryan,
Are you able and willing to act as release manager for 3.0?
On 8/6/2015 11:56 AM, Bryan Thompson wrote:
Just release to encourage
Peter? Anyone?
I have time, but not the knowledge. I would be willing to be release
manager provided at least one person who knows how it is done will
provide a lot of step-by-step guidance.
On 8/8/2015 7:21 AM, Bryan Thompson wrote:
Not really I am afraid. I am quite heavily committed
Hello all:
Please review and vote on the release of Apache River Examples v1.0
The staging repository is at:
https://repository.apache.org/content/repositories/orgapacheriver-1001
https://repository.apache.org/content/repositories/orgapacheriver-1001
And the source release ‘zip
Is there anything that needs to be done before calling for a PMC vote on
the release?
On 8/6/2015 11:56 AM, Bryan Thompson wrote:
Just release to encourage people to use it. +1 on release.for me.
On Aug 6, 2015 2:55 PM, Patricia Shanahan p...@acm.org wrote:
Would it be useful to tag
for them.
Cheers,
Greg Trasuk
On Aug 7, 2015, at 2:54 AM, Patricia Shanahan p...@acm.org wrote:
Is there anything that needs to be done before calling for a PMC vote on the
release?
On 8/6/2015 11:56 AM, Bryan Thompson wrote:
Just release to encourage people to use it. +1 on release.for me
the dependencies at
runtime, or setup and document a separate download process for them.
Cheers,
Greg Trasuk
On Aug 7, 2015, at 2:54 AM, Patricia Shanahan p...@acm.org wrote:
Is there anything that needs to be done before calling for a PMC vote on the
release?
On 8/6/2015 11:56 AM, Bryan
. Of the other ones, I suspect that the
‘reggie-nameservice-provider’ could be generated. Most of the others are older
versions of packages that are available from Maven Central. Only
‘animal-sniffer’ and ‘asm 3.2’ are present in the river-2.2.2 release and I
don’t think animal-sniffer
Would it be useful to tag it as a 3.0 beta release initially, or just go
to 3.0 and add point releases as needed?
I will vote in favor of releasing it either way.
On 8/6/2015 9:55 AM, Bryan Thompson wrote:
Or just release it. If problems emerge, people can report them and they
can get fixed
Just release to encourage people to use it. +1 on release.for me.
On Aug 6, 2015 2:55 PM, Patricia Shanahan p...@acm.org wrote:
Would it be useful to tag it as a 3.0 beta release initially, or just go
to 3.0 and add point releases as needed?
I will vote in favor of releasing it either way
I can free up some cycles. Unfortunately, the last time I was closely
involved in a software release was over 30 years ago - I switched to
system performance and hardware architecture. Even then, I was the
compiler project leader, not the release coordinator.
On the other hand, I can free up
Java 8. I’m planning to apply that patch soon and spin a release of
2.2.x as well.
Cheers,
Greg Trasuk
On Apr 30, 2015, at 11:23 AM, Dawid Loubser da...@travellinck.com wrote:
I strongly support this! Peter's work needs to get out there and be
battle-proven, and anything that even inches
Sounds good. Does Apache do release candidates as well? If not,
let's make sure that the existing deployed footprint (which is large)
has a chance to evaluate the branch before the 3.0 release.
Bryan
On Thu, Apr 30, 2015 at 11:13 AM, Dennis Reedy dennis.re...@gmail.com wrote:
Hi,
I didn’t
Hi,
I didn’t want to add this to the thread that Patricia started, but IMO I’d like
us to push for a new release ASAP. Peter’s done a ton of work, there are
improvements needed to the RMI classloading approach that can help projects out
there today that use OSGi, and we have to do something
17:13, Dennis Reedy wrote:
Hi,
I didn’t want to add this to the thread that Patricia started, but IMO I’d
like us to push for a new release ASAP. Peter’s done a ton of work, there are
improvements needed to the RMI classloading approach that can help projects
out there today that use OSGi
Apache is kind of like Yoda - release or do not, there is no candidate. ;- )
“Release” is more of a licensing thing.. We’re putting out the Foundation’s
assurance that the code is Apache-licensed and of known provenance. River is
perfectly free to put out a release where we can’t swear
suppose
if a given user’s build system uses classdep, then it would be a problem as
well. Do people often use classdep? I never have.
Having said that, there was a patch contributed to make the build system work
under Java 8. I’m planning to apply that patch soon and spin a release of
2.2.x
I would have sworn that we had consensus six months ago to merge Peter’s work
from the qa_refactor branch back onto the trunk. Peter needs to declare it
“done”, and other people need to look at it, then someone needs to release it.
Unfortunately I don’t have the spare cycles to act as release
than a “3.0”
release.
I’m still unnerved by the massive amounts of changes to both code and
tests in the qa_refactor branch, as well as the apparent instability
of the code, although that seems to be improving. In the next few
weeks I’m going to try and setup a cross-test case
versioning
policy, so we’d be looking at the “2.3” branch rather than a “3.0”
release.
I’m still unnerved by the massive amounts of changes to both code and
tests in the qa_refactor branch, as well as the apparent instability
of the code, although that seems to be improving
change according to our versioning
policy, so we’d be looking at the “2.3” branch rather than a
“3.0” release.
I’m still unnerved by the massive amounts of changes to both
code and tests in the qa_refactor branch, as well as the
apparent instability of the code, although
than a
“3.0” release.
I’m still unnerved by the massive amounts of changes to both
code and tests in the qa_refactor branch, as well as the
apparent instability of the code, although that seems to be
improving. In the next few weeks I’m going to try and setup
a cross-test case, to see what
think that
would be a “minor” version change according to our versioning
policy, so we’d be looking at the “2.3” branch rather than a
“3.0” release.
I’m still unnerved by the massive amounts of changes to both
code and tests in the qa_refactor branch, as well
.
- Original message -
Assuming that there aren’t major incompatibilities, I think
that would be a “minor” version change according to our
versioning policy, so we’d be looking at the “2.3” branch
rather than a “3.0” release
be a “minor” version change according
to our versioning policy, so we’d be looking at the
“2.3” branch rather than a “3.0” release.
I’m still unnerved by the massive amounts of changes to
both code and tests in the qa_refactor branch, as well
think
that would be a “minor” version change according to our
versioning policy, so we’d be looking at the “2.3” branch
rather than a “3.0” release.
I’m still unnerved by the massive amounts of changes to
both code and tests in the qa_refactor branch, as well as
the apparent instability
.
- Original message -
Assuming that there aren’t major incompatibilities, I
think that would be a “minor” version change according
to our versioning policy, so we’d be looking at the
“2.3” branch rather than a “3.0” release.
I’m
Assuming that there aren’t major incompatibilities, I think that would be a
“minor” version change according to our versioning policy, so we’d be looking
at the “2.3” branch rather than a “3.0” release.
I’m still unnerved by the massive amounts of changes to both code and tests
- Original message -
Assuming that there aren’t major incompatibilities, I think that would
be a “minor” version change according to our versioning policy, so we’d
be looking at the “2.3” branch rather than a “3.0” release.
I’m still unnerved by the massive amounts of changes
I'm happy to accept whatever release version number that the committers decide
when that time comes.
I think it best to narrow our focus for now on how to proceed with the release
process.
Regards,
Peter.
- Original message -
The way that services are instantiated and setup
:
The vote passed with +1s from Greg Trasuk, Dennis Reedy, Jonathan Costers and
Peter Firmstone.
I will release the Maven artifacts immediately, but it will take me a day or
two to do the distribution website. Announcement will follow when all that
is done.
Cheers,
Greg Trasuk.
The vote passed with +1s from Greg Trasuk, Dennis Reedy, Jonathan Costers and
Peter Firmstone.
I will release the Maven artifacts immediately, but it will take me a day or
two to do the distribution website. Announcement will follow when all that is
done.
Cheers,
Greg Trasuk.
+1 Peter.
- Original message -
Apache River 2.2.2 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that add support for JMX entries and
publish additional artifacts to the Maven repository.
Release Notes - River - Version River_2.2.2
** Bug
Apache River 2.2.2 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that add support for JMX entries and
publish additional artifacts to the Maven repository.
Release Notes - River - Version River_2.2.2
** Bug
* [RIVER-423] - Add JSR 160 classes to project
+1 : Greg Trasuk
On Tue, 2013-11-12 at 14:42, Greg Trasuk wrote:
Apache River 2.2.2 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that add support for JMX entries and
publish additional artifacts to the Maven repository.
Release Notes - River - Version
+1
Jonathan Costers
Op 12-nov.-2013, om 20:42 heeft Greg Trasuk tras...@stratuscom.com het
volgende geschreven:
Apache River 2.2.2 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that add support for JMX entries and
publish additional artifacts
+1
Dennis Reedy
On Nov 12, 2013, at 242PM, Greg Trasuk tras...@stratuscom.com wrote:
Apache River 2.2.2 is a maintenance release based on the Apache River
2.2 branch, primarily with fixes that add support for JMX entries and
publish additional artifacts to the Maven repository.
Release
, and I'd like to propose a release of the 2.2 branch to
get these fixes out.
Anyone have an issue with a maintenance release of the 2.2 branch?
No objections, probably a good idea.
After that, I think we need to revisit the trunk (2.3?) branch and talk
about how to go about releasing
The vote has carried.
+1's from Dennis, Greg and Peter.
+0 from Sim
Greg.
On Tue, 2013-05-14 at 21:17, Greg Trasuk wrote:
Hi all:
The staging repository below contains the Maven artifacts based on the
Apache River 2.2.1 release that was approved on May 3. Please review
and vote
Hi all:
The staging repository below contains the Maven artifacts based on the
Apache River 2.2.1 release that was approved on May 3. Please review
and vote for or against promoting these artifacts to released status,
which will be published to Central.
Cheers,
Greg.
[ ] +1 : I approve
+1.
Greg.
On Tue, 2013-05-14 at 21:17, Greg Trasuk wrote:
Hi all:
The staging repository below contains the Maven artifacts based on the
Apache River 2.2.1 release that was approved on May 3. Please review
and vote for or against promoting these artifacts to released status,
which
Binding:
Peter Firmstone +1
Simon IJskes+0 (not time to evaluate the results)
Dennis Reedy+1
Greg Trasuk +1
Non-Binding
Dan Rollo +1
With 3 binding +1's the release is approved. I'll start the process.
Cheers,
Greg Trasuk
Greg,
Awesome and thank you so much for being he release manager and moving it
through. Lets please get the release published as artifacts to Maven central.
Regards
Dennis
On May 4, 2013, at 823PM, Greg Trasuk wrote:
Binding:
Peter Firmstone +1
Simon IJskes +0 (not time
Hi all:
Please vote on this release. If necessary I'll hold the vote open until
we get suffuient response, but I'd prefer to get it closed off. At the
present time, we have only seen 1 vote.
Cheers,
Greg.
-Forwarded Message-
From: Greg Trasuk tras...@stratuscom.com
To: dev
Successful Jenkins build here, by the way...
https://builds.apache.org/job/river-2.2-qa-jdk7/6/
Cheers,
Greg.
On Wed, 2013-05-01 at 12:00, Greg Trasuk wrote:
Hi all:
Please vote on this release. If necessary I'll hold the vote open until
we get suffuient response, but I'd prefer to get
+1
On May 1, 2013, at 1200PM, Greg Trasuk wrote:
Hi all:
Please vote on this release. If necessary I'll hold the vote open until
we get suffuient response, but I'd prefer to get it closed off. At the
present time, we have only seen 1 vote.
Cheers,
Greg.
-Forwarded Message
/ shared development branch might be more appropriate
than the current trunk model.
In hindsight, it's lucky the small trunk commits caused those breakages,
I was ready to release a codebase with concurrency bugs likely to show
up in production.
It's important for people to remember
101 - 200 of 355 matches
Mail list logo
