[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] multiple --local-dir options

From: Pádraig Brady
Subject: Re: [PATCH] multiple --local-dir options
Date: Wed, 9 Dec 2015 01:35:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 07/12/15 10:46, Pádraig Brady wrote:
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]