Sean, Do you mind updating the contributor guide to reflect a preference (but not at the exclusion of)?
Regarding the muti-module do you think that is superior to simply having activated profiles for now? I just want to avoid restructuring until we 'know' the need. Thanks Joe On Mon, Jun 29, 2015 at 4:14 PM, Sean Busbey <[email protected]> wrote: > On Mon, Jun 29, 2015 at 3:05 PM, Shawn Wells <[email protected]> wrote: > >> >> >> On 6/29/15 3:52 PM, Sean Busbey wrote: >> >>> If we added a set of modules for packaging options, I'd love that. >>> >>> Maybe nifi-assembly could become a multimodule with the existing tarball >>> as >>> one submodule and the rpm packaging as another? >>> >> >> I'm still familiarizing myself with the code and various installation >> steps, but this shouldn't be anything more than different make targets. An >> init script needs to be created to wrap bin/nifi.sh (but that's trivial). >> >> I'm working off RHEL7 and plan to build RPMs for that unless anyone >> screams loudly. >> >> > Sure, but if we're going to support multiple packaging options for our > assembly it's better to just bite the bullet now and set things up so that > if we end up with options that require more files we have a clear > separation of concerns. a dedicated module also eases documentation, since > github can only render one README.md per directory. > > > >> Once I have some working code and process documentation, would the best >> way to start be to open a PR @ https://github.com/apache/incubator-nifi/ ? >> >> > We can handle PRs, but it's still awkward. You'll need to open a JIRA for > the addition regardless[1], and it'll probably be easier if you attach a > patch to that ticket rather than open a github PR. Of course, we'd rather > committers do more work if it gets more contributions, so use a PR if > making a patch turns out to be a burden. > > > >> My big concern with EPEL would be keeping current as NiFi adds new >>> versions. But so long as a user of an EPEL publish RPM could upgrade to a >>> newer one released by the project I'd be +1. >>> >> >> EPEL packages have the advantage of doing releases whenever the package >> maintainer(s) want :) >> >> Being able to "yum install nifi" has really positive user experience >> implications for the guys I'm working with. I'm not sure how upgrading >> would work yet, mostly because I've never done a nifi upgrade (I've only >> gotten my feet wet with 3 installs). >> >> > Well that handles my concerns. :) > > Who would be the package maintainer(s)? Presumably they are named > individuals? > > > [1]: https://issues.apache.org/jira/browse/NIFI/ > > -- > Sean
