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?
Katja
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?
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.
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
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
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
On Thu, 2015-12-17 at 19:20 +0100, Fred Jan Kraan wrote:
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.
Exactly. This is why there is a version field in deken packages.
I don't see how something like a fork map helps the end user, i. e. the one using Pure Data and installing an external through deken. When you install something with deken, you primarily want to know what sources have been used to build that package. Once you know that, you might also want to know where those sources are forked from. Currently, you only know _who_ as uploaded a package, but you do not know _where_ the sources of a package are hosted.
I'm not opposing the idea of a fork map, but there is more important information missing before that.
Roman
According to the FAQ at gnu .org (http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary): I downloaded just the binary from the net. If I distribute copies, do I have to get the source and distribute that too?
Yes. The general rule is, if you distribute binaries, you must distribute the complete corresponding source code too. The exception for the case where you received a written offer for source code is quite limited.
...doesn't this imply that deken should also provide the source code itself, at least as an option?
Martin
On Tue, Dec 22, 2015 at 8:07 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2015-12-17 at 19:20 +0100, Fred Jan Kraan wrote:
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.
Exactly. This is why there is a version field in deken packages.
I don't see how something like a fork map helps the end user, i. e. the one using Pure Data and installing an external through deken. When you install something with deken, you primarily want to know what sources have been used to build that package. Once you know that, you might also want to know where those sources are forked from. Currently, you only know _who_ as uploaded a package, but you do not know _where_ the sources of a package are hosted.
I'm not opposing the idea of a fork map, but there is more important information missing before that.
Roman
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On 23/12/15 00:30, Martin Peach wrote:
...doesn't this imply that deken should also provide the source code itself, at least as an option?
https://github.com/pure-data/deken/issues/88
Cheers,
Chris.
On 2015-12-22 17:30, Martin Peach wrote:
...doesn't this imply that deken should also provide the source code itself,
no. it only implies that anybody who uploads the binaries for some GPL licensed library, also must provide the source code.
it's not really a problem of deken...
at least as an option?
...but then deken makes it a tad too easy to do the "wrong thing" (publish binaries without sources). Hence the ticket#88.
gmasdr IOhannes
-
Antoine Rousseau -
Chris McCormick -
Fred Jan Kraan -
IOhannes m zmoelnig -
katja -
Martin Peach -
Roman Haefeli