So perhaps a bit of history. nonoss/noredist is for targets that aren't built 'by default' (e.g. you must explicitly turn them on). We do this because the ASF wants the default build to be truly unencumbered and where there are dependencies on non-open source, or non-Apache compatible code, we typically turn them off. In example: historically, Netscaler libraries were not open source, and we had a dependency on those libraries, so we placed the netscaler plugin into the nonoss. Since then the netscaler libraries have been open sourced, and we could move those out of noredist.
So - is there third party code that you have as a build or runtime dependency? If so what is the license for that third party code? (My really fast perusal didn't catch anything that was immediately troubling) --David On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens <wstev...@cloudops.com> wrote: > Its dependence on a third party API and appliance, similar to the srx and > netscaler. I am not convinced it should be in noredist, but I was following > the same model as other similar plugins. Feedback on this would be > helpful. > > Ws > > On Tuesday, November 5, 2013, David Nalley wrote: > >> On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens >> <wstev...@cloudops.com<javascript:;>> >> wrote: >> > Sheng, I will rebuild the patch for the latest master. The latest master >> > has depreciated the 'nonoss' flag in favour of 'noredist'. I was building >> > in nonoss previously. I am guessing I should use the noredist flag now? >> > >> >> Will - what is causing this to be noredist/nonoss? My quick perusal of >> your patch didn't surface anything that would push it into that >> category. >> >> --David >>
