activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <>
Subject Re: Encouraging more on-list discussions (was Re: Temporary Branch for ARTEMIS-780)
Date Mon, 14 Nov 2016 16:00:51 GMT

IMHO, anything that gets more discussions and more people talking on the
mailing lists is a good first step.  I feel like we rarely ever hear from
Gao, Justin or Andy on list, would be nice to get them to say hi every now
and then :-)

Of course, there's nothing that can be done to force community
discussions.  It can only be encouraged.  There's also going to be certain
discussions that have to be in private.

I think its useful to have some kind of discussion about large impacting
changes, kind of Clebert's point.  For instance, we had a discussion
recently about moving to Java 8.  At first that was going to be the turning
point for a 2.0 (which sort of makes sense to me - it's an incompatible
change, you would need to upgrade your java version), but then it was
agreed to hold off.  So having another 2.0 change sort of sneak in seems a
little odd.

Antoine brings up great points as well.  I actually encourage projects to
discuss board reports in the incubator in public.  Most podlings graduating
in the last ~2 years have continued this pattern.  Older graduates not so
much.  So yeah, if all dev discussions were open that would be great.


On Mon, Nov 14, 2016 at 5:57 AM Martyn Taylor <> wrote:

> 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" <> 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 <>
> 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
> >

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