There are two workflows that we support: Jira/Review Board: - Create a ticket at http://issues.apache.org/jira under the Helix project - Submit a code review to http://reviews.apache.org, adding helix to the list of reviewing groups (there is also a tool called hpost-review.sh in the source that can automate review creation)
Github: - Submit issues and pull requests to https://github.com/apache/helix Thanks, Kanak ________________________________ > Date: Sat, 15 Feb 2014 22:06:56 -0800 > Subject: Re: Helix 0.6.2: InstanceConfigChangeListener not implemented > by GenericHelixController > From: [email protected] > To: [email protected] > > Is there a document on how to submit patches, code. I will be happy to > help with small fixes like this one if you guys can point me to the > right process to submit patches. > > Sandeep > > > On Sat, Feb 15, 2014 at 10:00 PM, Kanak Biscuitwala > <[email protected]<mailto:[email protected]>> wrote: > Hi Sandeep, > > I agree with this assessment and certainly apologize for the confusion. > I created a ticket so that this can be looked at as part of our plans > to improve controller plugability in the near future. > > Please let us know if there is anything else we can help clarify as you > get started with Helix. We're interested in any feedback you might have > as we try to improve the onboarding flow. > > Kanak > > ________________________________ >> Date: Sat, 15 Feb 2014 21:51:26 -0800 >> Subject: Re: Helix 0.6.2: InstanceConfigChangeListener not implemented >> by GenericHelixController >> From: [email protected]<mailto:[email protected]> >> To: [email protected]<mailto:[email protected]> >> >> Hi Kanak, >> >> The javadocs on HelixManager state that ConfigChangeListener is >> deprecated and is replaced by InstanceConfigChangeListener. If the >> ConfigChangeListener is deprecated shouldn't the GenericHelixController >> implement the InstanceConfigChangeListener even if the paths are the >> same? I think the GenericHelixController internally should >> wrapper/delegate or bridge from the new to the old interface until it >> gets removed. >> >> I am sure the deprecation was put in place with the intention that the >> old interface will go away (be removed) in subsequent releases so I >> imagine you actually want people to reference the new interface in new >> code/projects that use Helix and not recommend them to reference the >> old one. That way when time comes you can remove it with less >> dependencies needing to be realigned. >> >> Like I said before IMO the GenericHelixController should implement the >> new interface so it is clear. >> >> As regards the question of me extending that base implementation. At >> this point I am trying to get an understanding of how Helix works by >> prototyping. When I saw the new interface it was unclear if I had to >> implement it myself as it appeared to be so because there were no >> default implementations. I am hoping I won't have to if the Default >> implementation works fine for me and I will be perfectly happy to use >> it. >> >> Thanks, >> >> Sandeep >> >> >> On Sat, Feb 15, 2014 at 9:33 PM, Kanak Biscuitwala >> > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > > wrote: >> By the way, right now if the default controller is fine for your >> system, you don't actually have to instantiate your own >> GenericHelixController. HelixManager (when started with instance type >> CONTROLLER) will do this for you automatically with all the listeners >> registered. >> >> Kanak >> >> ---------------------------------------- >>> From: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > >>> To: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > >>> Subject: RE: Helix 0.6.2: InstanceConfigChangeListener not >> implemented by GenericHelixController >>> Date: Sat, 15 Feb 2014 21:30:31 -0800 >>> >>> Hi Sandeep, >>> >>> GenericHelixController implements ConfigChangeListener instead of >> InstanceConfigChangeListener mostly for backwards compatibility >> reasons. Both listeners listen on the same path, so changing an >> instance config will still trigger the controller pipeline. Thus, you >> don't need to extend the controller just so that it implements this one >> interface. >>> >>> May I know why the default controller implementation might fall short >> in your system? >>> >>> Kanak >>> >>> Date: Sat, 15 Feb 2014 21:23:42 -0800 >>> Subject: Helix 0.6.2: InstanceConfigChangeListener not implemented by >> GenericHelixController >>> From: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > >>> To: > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > >>> >>> Hi all, >>> >>> I am trying to get a prototype going with Helix 0.6.2 and noticed >> that the HelixManager instance can take instances of Change Listeners. >> One of the new change listeners is InstanceConfigChangeListener. As per >> the documentation I can create an instance of the >> GenericHelixController and register it as a listener for pretty much >> all other listeners but not InstanceConfigChangeListener. >>> >>> InstanceConfigChangeListener replaces ConfigChangeListener which was >> implemented by the GenericHelixController but it does not implement the >> InstanceConfigChangeListener. Is this by design? >>> >>> I do plan to eventually look at whether I need to add my own >> implementation or extension to the GenericHelixController but for now >> want to get a quick prototype working, so is there a default >> implementation for the InstanceConfigChangeListener I can use? >>> >>> Thanks, >>> >>> Sandeep >> >
