I think its already agreed it makes sense.
We just need to make a proposal and a scope then.
On Fri, Jun 23, 2017 at 9:35 PM Von Gosling wrote:
>
> Hi,
>
>
> I am not sure your mention is Apache RocketMQ. In RocketMQ, jms
> integration is just a adaptor, while not fully support JMS 1.1 and JMS
Hi,
I am not sure your mention is Apache RocketMQ. In RocketMQ, jms integration is
just a adaptor, while not fully support JMS 1.1 and JMS 2.0 specification.
IMO, that’s a good idea. if we messaging engines can collaborate to some common
components, such as benchmark, common api specificatio
Hi,
As already been discussing in the Artemis mailing lists have some areas we
would like to contribute/commit in particular already looking at:
JMSObject Custom serdes wrapper (with and avro serdes as initial provided)
Generic JMS Client side persistence
Cheers
Mike
On 2017-06-22 04:39 (+
Dear Incubator members,
This vote has passed with the following result:
24 [+1] votes (8 binding, 16 non-binding)
Binding Votes:
Julien Le Dem
Raphael Bircher
Jake Farrell
Jacques Nadeau
Julian Hyde
Chris Douglas
John Ament
P. Taylor Goetz
Non-binding Votes:
This vote is now close and it has passed. Thanks to all who all who
participated in the proposal review and vote.
The vote tally is as follows:
24 [+1] votes (8 binding, 16 non-binding)
Binding Votes:
Julien Le Dem
Raphael Bircher
Jake Farrell
Jacques Nadeau
Julian Hyde
Chris D
I like the idea of focusing around the podling life-cycle.
On Thu, Jun 22, 2017 at 9:49 AM, Patrick Hunt wrote:
> On Sat, Jun 17, 2017 at 5:35 AM, John D. Ament
> wrote:
>
> > All,
> >
> > I'd like to start the process to move forward on a new incubator website.
> > Based on discussions in th
+1 to Ted’s comment.
As a user, I would love to pick one system and reuse the storm topologies.
Ideally pick one converged solution.
+1 to the incubation since it will eventually lead to a better options within
Apache.
debo
On 6/23/17, 10:08 AM, "Ted Dunning" wrote:
Anybody who worries
Anybody who worries about you serving as mentor needs a dose of reality.
They can't get anybody better.
On Jun 22, 2017 12:21 PM, "P. Taylor Goetz" wrote:
if there are ongoing concerns from either the Storm PMC or the Heron PPMC
about me acting as a mentor, I would be willing to step down.
+1 (
"*"We believe that
having Heron at Apache will help further the growth of the streaming
compute community, as well as encourage cooperation and developer cross
pollination with other Apache projects."
I realize that each incubator proposal has a statement like this. What I am
saying is entering th
Thanks John. We'll keep the originally posted vote close time then.
To answer your previous question about protocol, basically yes at the user
spec/API level used to author topologies, but not at the internal APIs and
communications protocol, those are different. It's roughly analogous to two
diff
Based on the additional comments, I'm OK with this continuing graduation.
I would like the proposed podling to undertake a specific task to ensure
its clear what is different between Storm and Heron, to avoid any
unexpected competition or user confusion.
John
On Fri, Jun 23, 2017 at 12:32 PM Juli
Hi Edward,
A better comparison is SQL. Heron provides an implementation of the Storm
topology api just like a query engine would implement SQL.
It is a statement to the Storm API that it became a reference for
streaming. This is the shared component and I agree that both projects
should collaborat
This would be totally from a Messaging Point of View.. not just JMS BTW.
Right now there are 2 JMS components that would be cross used from qpid-jms,
artemis.. and who knows… Rocket…
- Serders/Serialization integration for Object messages
- JMS Connection pool…
There’s also the idea of using th
Hi Eric,
Thanks for your checking, we had ignored those files in configuration before,
but we should double check our artifacts.
We will fix those license issue.
William
On 6/23/17, 8:55 PM, "Eric Friedrich (efriedri)" wrote:
Hi,
I checked the following:
- Filename of "apa
Thanks Justin for your vote.
We will fix the license issue as your mentioned.
Thanks,
William
On 6/23/17, 9:21 PM, "Justin Mclean" wrote:
Hi,
Sorry but it's -1 from me due to license issues. If other IPMC members
think it OK to release this I’ll change my vote. I do note this i
"The only overlap is that Heron supports the Storm user API for ease of
migration."
It sounds possible possible that storm could be one user facing API with
two back ends inside one project.
"Accumulo vs HBase" I do not think Accumulo and HBase is a valid comparison
one did not start out to emula
Hi,
Sorry but it's -1 from me due to license issues. If other IPMC members think it
OK to release this I’ll change my vote. I do note this is your first release
and the missing licenses (that I checked) do seem to be BSD/MIT licenses.
Also part of the issue here is that there’s a LICENSE and a
Hi,
I checked the following:
- Filename of "apache-griffin-0.1.4-incubating" would be preferred
- GPG signature validates
- MD5 and SHA1 signatures validate but it would be nice to release in a format
that allows the tools to check automatically with "-c" option (see manpage)
- Many .sh files n
Bill,
Would I be correct in understanding that Heron implements the same protocol
as Storm, but the actual implementation is different?
John
On Fri, Jun 23, 2017 at 1:36 AM Bill Graham wrote:
> It's grossly inaccurate to refer to Heron as a Storm fork. There are about
> 132k lines of code in t
+1
Alex Lv
From: William Guo
Sent: Friday, June 23, 2017 10:21:24 AM
To: general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]
Dear IPMC,
This is a call for a vote on releasing Apache G
+1
Alex Lv
From: William GUO on behalf of William Guo
Sent: Friday, June 23, 2017 11:01:34 AM
To: William Guo; general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: Re: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]
update text as
21 matches
Mail list logo
