On 23/11/15 12:01, Pavel Raiskup wrote: > On Monday 23 of November 2015 11:31:15 Pádraig Brady wrote: >> On 23/11/15 08:30, Pavel Raiskup wrote: >>> Hello maintainers, >>> >>> I planned to reuse some of my local gnulib modules in multiple projects. >>> >>> Because the modules are not yet ready to be proposed against gnulib >>> master, I need to keep track them "downstream". Its painful however to >>> C&P the local module contents all the time from project_A to project_B. >>> >>> The attached patch would help a lot: >>> >>> $ cd project_A >>> $ git submodule add project_B /path/to_project_B >>> $ gnulib --local-dir project_B/gl --local-dir gl ... >>> >>> Thanks for considering, >> >> While a nicely written and documented change, >> it's quite invasive. > > I agree. I was too quite surprised and tempted to give up. But to me > this is really worth applying.. > >> I have the niggling feeling that if multiple projects >> need something, then it should just be pushed upstream? > > At the end of the day, yes, but... > >> What are the conditions that would warrant this? Licensing? > > .. In my my case it is lack of willingness and man-power to write the code > portably and properly enough **NOW**. To be able to mark the code as > "gnulib-ready" and wait for upstream inclusion (not everybody is able to > commit to gnulib). Gnulib is about stability -- and the newly developed > API can grow somewhere else (and bother different people than gnulib > maintainers while stabilizing). > I can imagine however that licensing could be issue too.
I'm still concerned that merging this will increase complexity and facilitate tech debt by supporting out of tree modules being shared across multiple projects. Though it's well written and refactored. I'm 60:40 for merging and will do so soon unless others object. thanks, Pádraig
