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@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@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev