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