activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martyn Taylor <mtay...@redhat.com>
Subject Re: Encouraging more on-list discussions (was Re: Temporary Branch for ARTEMIS-780)
Date Mon, 14 Nov 2016 10:57:09 GMT
John,

Sure +1.  Let's try to improve on this.

The case in question, I had thought the creation of the JIRA was enough, to
at the very least, kick off discussion with interested parties.  I've tried
to keep this updated with latest changes but, have probably focused too
much on the code and not put as much information on the JIRA as I could
have.  Let's rectify this by adding as much info on the JIRA as possible
and ensuring that any discussion takes place here.

I added a document of my findings and outlined approach before you
re-titled this thread, a couple of days ago.  I'll also add comments to the
sub tasks to reflect the code changes on the branch.

I think roadmap discussions on list as Antoine suggested is a good call.
I'd be happy to drive this if people think this is the way forward?

Cheers
Martyn

On 11 Nov 2016 4:37 p.m., "John D. Ament" <johndament@apache.org> wrote:

> All,
>
> Changing the title to be a bit more direct about the issue at hand (in my
> opinion).
>
> I think the main concern I have about ARTEMIS-780 is the implicit
> ramifications on creating a 2.0 release.  Granted, I missed the original
> note, but then when it was mentioned in a further discussion as having
> impact I questioned where it had come from.  (realistically, saying there's
> a branch doesn't given much info about why there's a branch)
>
> We run into this kind of problem a lot in the Apache Incubator, when a
> company donates some amount of code to the ASF and has salaried employees
> work on that code.  Typically what happens is those employees have their
> own internal backlog and figure out where the code has to go (e.g.
> Apache).  There's nothing wrong with that model.  However, in the spirit of
> building a community, we need to encourage that when things are coming into
> the ASF code base there's a general understanding of what the idea is, and
> how to get others involved in it.
>
> The evidence from ARTEMIS-780 is that there's a high volume of discussion
> happening around how to implement it, not on any of these lists.  My ask to
> the overall community is to try to keep the entire ActiveMQ community
> engaged in large impacting discussions like this one to help foster more
> information, give those of us who aren't as familiar with the code a better
> understanding of how changes are coming in and what those changes are.
>
> John
>
> On Fri, Nov 11, 2016 at 5:26 AM Martyn Taylor <mtaylor@redhat.com> wrote:
>
> Hi John,
>
> Apologies for not getting to this sooner, I have taken some time out to
> write up more background , problems and what the proposal is.  I'll add it
> to the JIRA as soon as I'm done.  The crux of this change is adding the
> ability to define various destination types / behaviours (things like being
> able to define a non shared subscription queue for example) in a single
> unified way in core vs on a per protocol basis (like with JMS).  The fact
> that adding common behaviours like simple pub/sub in the protocol modules,
> and having no way (other than JMS which has it's own issues) to allow a
> user to define a pub/sub endpoint has been a real issue.
>
> This would also involve moving the current JMS way of doing things, to the
> new model.  And is actually the main bulk of the work.  As It turns out.
> the current JMSisms have leaked into many areas of the core engine and
> other protocols, trying to remove it has been a pain.  I already had an
> idea that this would be the case, hence the branch., but turned out to be a
> lot more that I had expected
>
> Re: Your use case, just to assure you, the idea is not to remove any of the
> existing core concepts, everything you can do now, you'll continue to be
> able to do after the change.  There might be some slight configuration
> changes in the new scheme to expose new functionality and move away from
> the specific JMS stuff, but I'm going to provide a tool for migrating
> configurations (the changes aren't big, just the exposing of the new
> addressing model and removal of the JMS specifics).
>
> I look forward to talking to you more on the JIRA.  I also like to hear use
> cases from Artemis users :) so I'd be interested to hearing more about what
> your doing.  It might be that these changes make things a bit easier for
> you.
>
> Cheers
> Martyn
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message