On 14 November 2016 at 16:00, John D. Ament <johndam...@apache.org> wrote:
> All, > > 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 :-) > I'll try harder John :) > > 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. > > John > > On Mon, Nov 14, 2016 at 5:57 AM Martyn Taylor <mtay...@redhat.com> 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" <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 > > > > > >
