[PD-dev] overview of upstream sources?

Antoine Rousseau antoine at metalu.net
Thu Dec 17 20:30:12 CET 2015


Hi all,

I've just forked my moonlib externals there :
https://github.com/MetaluNet/moonlib
So I've been able to update it a bit, and to convert the makefile to
pd-lib-builder system.

I'll soon try to upload with deken the binaries that I can make
(linux32/linux64/osx for now).
Also I will reference the url on my pd homepage.



2015-12-17 19:20 GMT+01:00 Fred Jan Kraan <fjkraan at xs4all.nl>:

> Hi All,
>
> On 2015-12-17 10:21 AM, Roman Haefeli wrote:
>
>> On Wed, 2015-12-16 at 14:34 +0100, katja wrote:
>>
>>> With the decentralization of Pd lib version control it is hard to
>>> locate / identify upstream source repositories. Would it be feasible
>>> and useful to generate (and regularly update) an overview of forks
>>> based on http://git.puredata.info/cgit/, to be referenced from
>>> http://puredata.info/docs/developer/GettingPdSource?
>>>
>>
>>
>> I believe it would be hard to maintain such an overview. Who has to
>> maintain such a list? How can you control that people adhere to the
>> standards?
>>
>
> There are probably two types of 'forks'; one which maintains a library of
> objects as is and one which is more like a remix of objects from different
> libraries, combined for some specific purpose.
>
> For at least the former is would be nice to have a description of the
> relation between the different forks.
>
>
>> I would rather propose adding some mandatory meta information to deken
>> uploads. A package that can be downloaded from puredata.info should at
>> least contain the information which sources it was built from.
>>
>
> The puredata.info could host such a list in the public wiki.
>
> It is not very convenient to download several packages just to find out
> the most recent/bug free.
>
>>
>> Further, I think it is the duty of the maintainer of a fork to make
>> clear what the origin of the fork is.
>>
>> If those two things are considered, we have transparency and identifying
>> upstream should be feasible.
>>
>> Roman
>>
>>
> Fred Jan
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20151217/d9db7084/attachment.html>


More information about the Pd-dev mailing list