I like Bart's idea of separating the repositories completely having an apache-hop-plugins repository along side the separate repository for things that may not be compatible from a license standpoint.
Since there are no autobuilds or packages sitting around of these other plugins, I think it makes it very difficult to discover and put the plugins to use. Matt's idea of a marketplace of sorts would be nice. I liked the marketplace from prior times, even if it was built off an XML submission. It was something usable. Brandon On Thu, Jun 24, 2021 at 2:45 AM Bart Maertens <[email protected]> wrote: > Hi All, > > >>> - Neo4j: The Neo4j Output plugins. I do believe that Bart Maertens > wrote > >>> the original version of that code so if he agrees to donate that code > we're > >>> fine there. > There's probably no original code left, but absolutely fine by me > > Agreed on the process to let new plugins move through the hop-plugins > repository. We could use that repository as some sort of internal > incubating repository, where plugins have to mature before they are > accepted in the incubator-hop repository. > > We may need to think of a way to separate incubator-hop candidate plugins > from plugins that can never make it into Apache Hop because of license or > dependency incompatibilities (which is currently the case for all plugins > in the repository). That is not an issue at the moment, but may get harder > once the number of external plugins starts to grow. > One option could be to keep the current hop-plugins repository for > incompatible plugins and create an additional > apache-hop-plugins repository. > > Regards, > Bart > > On Wed, Jun 23, 2021 at 6:48 PM Matt Casters <[email protected] > .invalid> > wrote: > > > Hello Devel-hoppers, > > > > Over the course of the last couple of months we've imported some > additional > > 3rd party source code. > > As was mentioned earlier during release voting we need to do a better job > > of making sure that we have permission to donate said code to Apache. > > For everything related to my own code and the Neo4j plugins I can be > formal > > the following are donated: > > - Code we imported: kettle-beam, pentaho-pdi-dataset, > kettle-debug-plugin, > > kettle-needful-things, kettle-environment, kettle-splunk, kettle-kafka > > - Neo4j: The Neo4j Output plugins. I do believe that Bart Maertens wrote > > the original version of that code so if he agrees to donate that code > we're > > fine there. > > > > Obviously for as far as myself is concerned: everything I added to the > > incubator-hop source code is also covered by my ICLA and a number of > > sources were mentioned in the incubation proposal. > > I'm just trying to be complete since apparently I've been a proficient > > coder lately :-) > > > > Recently we removed some old SQL parser code (good riddance). > > > > Since everything in Hop is a plugin anyway I suggest that if we're even a > > little bit uncertain about the origin of the plugin source code (apart > from > > the original source code import/rewrite) that we simply move it out into > > the external plugins <https://github.com/project-hop/hop-plugins> until > we > > have clear permission of the original authors to use the code. Going > > forward I suggest we do the opposite. Let's add code to the external > > plugins project first and only then incorporate it into incubator-hop > when > > we have a more formal permission to donate the code to the ASF. > > > > I believe that the list of debatable plugins is this: > > - MQTT input/output (originally from Hitachi) > > - Google Sheets (informal permission received from JF Monteil, need to > > formalize) > > - Google Analytics (originally from Hitachi) > > - Dropbox (permission needed from L. Coelho) > > > > The other new plugins were written from scratch and are fine I believe. > > > > Personally I think it's just not worth it to even have these discussions > > for a couple of obscure plugins so I would suggest moving this code out > of > > our way until we have clear SGAs for these plugins. > > > > Let me know what your thoughts are! Perhaps if we have more external > > plugins it forces us to build a software marketplace at some point. > > > > Question for our mentors: in what forms do these agreements need to come? > > Where are they stored and how are they communicated? > > > > Cheers, > > Matt > > -- > > Neo4j Chief Solutions Architect > > *✉ *[email protected] > > >
