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 <johndam...@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 <mtay...@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
