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 :-)
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 > > >
