It's open source, everything is contributed! So I'm not sure how having 'contrib' in the file structure serves a purpose.
We have src/python for the stuff that makes the Python module, so it seems like the natural thing to do is have src/nuke and src/maya for the code that makes plugins for those apps. On Sep 19, 2014, at 4:53 PM, Chad Dombrova <[email protected]> wrote: > Yes, I think this would be a great contribution. I know multiple places wish > they had it, or have written one like it but lament that they have to > redundantly maintain it. > > Cool. We're just about done with updating the Nuke plugin to the latest oiio > source. > > we can simply make the build system skip over those sections if no Maya or > Nuke or whatever SDKs are found in the obvious places at build time > > My thoughts exactly. > > Any suggestions on the folder structure? I was thinking: > > src/ > contrib/ > nuke/ > maya/ > > Alternately, contrib could be top-level. Suggestions on a better name than > contrib? integrations? > > chad. > > > > > > > -- lg > > > On Sep 10, 2014, at 7:21 AM, Chad Dombrova <[email protected]> wrote: > >> Hi all, >> We wrote tx reader/writer plugins for nuke and maya which have been really >> helpful to our pipeline (the nuke plugin in particular). Do you all think >> it makes sense to add them to the oiio repo as part of a contrib directory? >> >> The question is whether small connectors like these make sense as part of >> the main oiio library repo, or as separate repos. Having them as part of >> the main repo would encourage maintenance (for example, during refactors the >> code would be included in any find/replace operation), but it could add >> additional burden to the release process. >> >> My hope in open sourcing these tools is twofold: 1) that others will >> benefit from them, and 2) that Luma can crowd-source their maintenance. I >> don't want to release them under Luma's github account because I don't think >> they'll get the same attention and traction as they would if they were >> released within the oiio repo. If it's agreed that they don't make sense in >> the oiio repo, then I think it's worth considering if they should be hosted >> as new repos under the OpenImageIO github user. >> >> chad. >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
