activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <antoine.tou...@gmail.com>
Subject Re: Encouraging more on-list discussions (was Re: Temporary Branch for ARTEMIS-780)
Date Sat, 12 Nov 2016 01:32:16 GMT
On the Apache Buildr project (and I also witnessed it on the Apache Camel project) there is
open discussion of the roadmap and the objectives on the dev list.

The board is also discussing having the board reports of projects being prepared in the open
- making sure contributors see what the discussion topics are with the board.

In general, you want all dev activity of the project to happen in public.

I hope this helps.

Antoine

> On Nov 11, 2016, at 2:17 PM, Clebert Suconic <clebert.suconic@gmail.com> wrote:
> 
> What about trying to always open a design discussion on the dev list
> for new features?
> 
> I say trying because sometimes the thing is an obvious design decision
> and I don't think we need a rigid process, but whenever the task is
> pertinent, maybe we could encourage a design thread?
> 
> 
> On Fri, Nov 11, 2016 at 11:37 AM, 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
> 
> 
> 
> -- 
> Clebert Suconic


Mime
View raw message