To save extra discussion energy and *possibly* let the “cat out of the bag” let me say this: just wait a bit, something good is in the works to offer a solution to many of these problems.
I won't say anything more until the parties involved feel they are ready.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 6, 2015, at 11:39 AM, pd-list-request@lists.iem.at wrote:
I know I'm missing much of the technical details, but my idea is that if Pd Extended is up and running, it should be fairly easy for people to update libraries (like Fred is doing with cyclone now) and release an updated version with the updated objects... meaning we didn't have to wait for two years for a bug fix. But somehow this only makes sense in the "vanilla route".
[?][?][?][?][?]
2015-06-06 13:37 GMT-03:00 Dan Wilcox danomatika@gmail.com:
To save extra discussion energy and *possibly* let the “cat out of the bag” let me say this: just wait a bit, something good is in the works to offer a solution to many of these problems.
I won't say anything more until the parties involved feel they are ready.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Jun 6, 2015, at 11:39 AM, pd-list-request@lists.iem.at wrote:
I know I'm missing much of the technical details, but my idea is that if Pd Extended is up and running, it should be fairly easy for people to update libraries (like Fred is doing with cyclone now) and release an updated version with the updated objects... meaning we didn't have to wait for two years for a bug fix. But somehow this only makes sense in the "vanilla route".
On Sam, 2015-06-06 at 12:37 -0400, Dan Wilcox wrote:
To save extra discussion energy and *possibly* let the “cat out of the bag” let me say this: just wait a bit, something good is in the works to offer a solution to many of these problems.
I'm looking forward!
Roman
On 07/06/15 20:38, Roman Haefeli wrote:
On Sam, 2015-06-06 at 12:37 -0400, Dan Wilcox wrote:
To save extra discussion energy and *possibly* let the “cat out of the bag” let me say this: just wait a bit, something good is in the works to offer a solution to many of these problems.
I'm looking forward!
Well, the basic idea is this:
https://raw.githubusercontent.com/pure-data/deken/master/deken.gif
Cheers,
Chris.
hmm, looks like the "vanilla route" idea is taking place, awesome ;)
but ok, lets not to force the cat out of the bag, we'll hold on for that... one way or another, I'd still like to know more about why and how things are complicated with the current extended scenario in more details.
such as why would it have to be concentrated in "one person"? Why the build farm is gone and how hard would it be to put it all back and running? Why does it always have to be one or two versions behind vanilla and not just get the latest vanilla and "extend" it? And also, why does it seem to me the pd distros always get concentrated in one or just a handful of people?
Please help me out trying to figure this all out.
Thanks folks
2015-06-07 12:07 GMT-03:00 Chris McCormick chris@mccormick.cx:
On 07/06/15 20:38, Roman Haefeli wrote:
On Sam, 2015-06-06 at 12:37 -0400, Dan Wilcox wrote:
To save extra discussion energy and *possibly* let the “cat out of the bag” let me say this: just wait a bit, something good is in the works to offer a solution to many of these problems.
I'm looking forward!
Well, the basic idea is this:
https://raw.githubusercontent.com/pure-data/deken/master/deken.gif
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jun 7, 2015, at 6:44 PM, Alexandre Torres Porres porres@gmail.com wrote:
such as why would it have to be concentrated in "one person”?
Because that’s how the existing extended setup was originally built and maintained.
Why the build farm is gone and how hard would it be to put it all back and running?
Probably because the people maintaining it are no longer actively working with pd in their spare time. Setting it a new one involves money, time and maintenance. A sponsoring institution, as Jonathan, has pointed out would really help for those points.
Why does it always have to be one or two versions behind vanilla and not just get the latest vanilla and "extend" it?
It doesn’t have to be that way, but it takes *alot* of work to test things against new updates and changes. Pd extended not only bundled lots of externals but was a test bed for UI updates and other types of modifications to the core that could not be easily updated from the work being done ahead of it in vanilla.
Think of it as editing a book for an author. You get the latest version from him, you make some changes then you get a few other people to help add and move things around and now you have you “community edition of the book”. But, by that time, the original author has already changed a number of other things, some of which may conflict with your changes. So now updating your version with the author’s will take alot more time. This is the main reason why extended was always a little behind. It simply takes work and, unfortunately, Hans was really the only one doing it.
And also, why does it seem to me the pd distros always get concentrated in one or just a handful of people?
It’s open source. It doesn’t have to be that way but it is because it relies on people donating their time for free to do this work. Luckily, some people can do it as part of an institution, but not all.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 7, 2015, at 6:44 PM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
such as why would it have to be concentrated in "one person”?
Because that’s how the existing extended setup was originally built and maintained.
Why the build farm is gone and how hard would it be to put it all back and running?
Probably because the people maintaining it are no longer actively working with pd in their spare time. Setting it a new one involves money, time and maintenance. A sponsoring institution, as Jonathan, has pointed out would really help for those points.
Why does it always have to be one or two versions behind vanilla and not just get the latest vanilla and "extend" it?
It doesn’t have to be that way, but it takes *alot* of work to test things against new updates and changes. Pd extended not only bundled lots of externals but was a test bed for UI updates and other types of modifications to the core that could not be easily updated from the work being done ahead of it in vanilla.
Think of it as editing a book for an author. You get the latest version from him, you make some changes then you get a few other people to help add and move things around and now you have you “community edition of the book”. But, by that time, the original author has already changed a number of other things, some of which may conflict with your changes. So now updating your version with the author’s will take alot more time. This is the main reason why extended was always a little behind. It simply takes work and, unfortunately, Hans was really the only one doing it.
And also, why does it seem to me the pd distros always get concentrated in one or just a handful of people?
It’s open source. It doesn’t have to be that way but it is because it relies on people donating their time for free to do this work. Luckily, some people can do it as part of an institution, but not all.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 7, 2015, at 7:03 PM, Dan Wilcox danomatika@gmail.com wrote:
On Jun 7, 2015, at 6:44 PM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
such as why would it have to be concentrated in "one person”?
Because that’s how the existing extended setup was originally built and maintained.
Also it didn’t have to be that way, but that’s how it ended up. We don’t feel it’s sustainable to hope that someone else steps up to take it over and it’s not like the pd-extended sources are locked up until someone wants to pick it up. They are sitting there ready to be worked on again but no one has. Chris is right: code > talk.
It’s frankly a lot of work and it simply makes more sense to find a way to distribute alot of that which is the current approach that’s being taken. Split up the work so nobody really gets stuck in a bottle neck. Make it easy for people to download and install the externals they need with vanilla and for developers to respond to bugs etc so the feedback loop is faster and easier.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sun, 2015-06-07 at 19:44 -0300, Alexandre Torres Porres wrote:
such as why would it have to be concentrated in "one person"?
I don't think it has to be. It turned out to be like that when Hans was still working on it. It think it was because Pd-extended is designed in a way that required to make a lot of decisions. Spreading that decision process across a group of people makes it orders of magnitude more complex. I believe the very nature of a monolithic distribution naturally leads to this kind of complexity. For instance, the version number of Pd-extended does not only reflect the Pd version it is based on, but it also defines a certain state/version of all included externals with their current features and bugs. If an external author was fixing a bug, they had to create a new release of their external and wait for the next release of Pd-extended for their new release of the external to be included. A release of Pd-extended has been always a huge thing that took a lot of time and care. Pd-extended burdened itself with a lot of responsibility. Only the question alone of what is included and what not and could lead to endless debates when decided by many instead of one. It seems the solution to this problem is: Don't try to answer it at all, let the user decide. Which in turn means: 'Let's make it easy for devs to distribute their stuff' and 'Let's make it easy for users to find and install stuff'.
Why the build farm is gone and how hard would it be to put it all back and running? Why does it always have to be one or two versions behind vanilla and not just get the latest vanilla and "extend" it?
I can't tell you the exact details, since I haven't been involved, but I guess because the whole process of creating a release was so complex and time consuming. A new version of Pd had to be imported, the patches specific to Pd-extended had to be applied, anything that broke had to be fixed, new releases of the available externals had to be imported, everything had to be tested for bugs and regressions...
Also it has to be built for many platforms and architectures. It requires only one external build to fail for the whole build to fail. Until Pd-extended got built on all supported platforms and architectures successfully, there was no new release. I could imagine building alone is a huge task, considering that Ubuntu alone has 4-5 supported distro releases simultaneously.
And also, why does it seem to me the pd distros always get concentrated in one or just a handful of people?
When new flavors have been created, frustration has been a driving force, at least that was my impression. People wanted features and submitted patches and they get never accepted or simply ignored. Slow Pd development made some devs take things into their own hands and they started implementing whatever they desired. I don't think maintainability by the community was the driving concept. And when a flavor is not only a Pd flavor, but a whole distribution with a collection of libraries, then we are back at the discussion why it is so hard for a community to maintain a monolithic distribution.
Roman
what do you mean by "monolithic distribution"? cheers
2015-06-08 6:04 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Sun, 2015-06-07 at 19:44 -0300, Alexandre Torres Porres wrote:
such as why would it have to be concentrated in "one person"?
I don't think it has to be. It turned out to be like that when Hans was still working on it. It think it was because Pd-extended is designed in a way that required to make a lot of decisions. Spreading that decision process across a group of people makes it orders of magnitude more complex. I believe the very nature of a monolithic distribution naturally leads to this kind of complexity. For instance, the version number of Pd-extended does not only reflect the Pd version it is based on, but it also defines a certain state/version of all included externals with their current features and bugs. If an external author was fixing a bug, they had to create a new release of their external and wait for the next release of Pd-extended for their new release of the external to be included. A release of Pd-extended has been always a huge thing that took a lot of time and care. Pd-extended burdened itself with a lot of responsibility. Only the question alone of what is included and what not and could lead to endless debates when decided by many instead of one. It seems the solution to this problem is: Don't try to answer it at all, let the user decide. Which in turn means: 'Let's make it easy for devs to distribute their stuff' and 'Let's make it easy for users to find and install stuff'.
Why the build farm is gone and how hard would it be to put it all back and running? Why does it always have to be one or two versions behind vanilla and not just get the latest vanilla and "extend" it?
I can't tell you the exact details, since I haven't been involved, but I guess because the whole process of creating a release was so complex and time consuming. A new version of Pd had to be imported, the patches specific to Pd-extended had to be applied, anything that broke had to be fixed, new releases of the available externals had to be imported, everything had to be tested for bugs and regressions...
Also it has to be built for many platforms and architectures. It requires only one external build to fail for the whole build to fail. Until Pd-extended got built on all supported platforms and architectures successfully, there was no new release. I could imagine building alone is a huge task, considering that Ubuntu alone has 4-5 supported distro releases simultaneously.
And also, why does it seem to me the pd distros always get concentrated in one or just a handful of people?
When new flavors have been created, frustration has been a driving force, at least that was my impression. People wanted features and submitted patches and they get never accepted or simply ignored. Slow Pd development made some devs take things into their own hands and they started implementing whatever they desired. I don't think maintainability by the community was the driving concept. And when a flavor is not only a Pd flavor, but a whole distribution with a collection of libraries, then we are back at the discussion why it is so hard for a community to maintain a monolithic distribution.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/08/2015 11:55 PM, Alexandre Torres Porres wrote:
what do you mean by "monolithic distribution"?
a single zip-file containing a pd-binary (of extended flavour) and a large collection of externals.
gfmdsaf IOhannes
Hi there,
As I told it before, a student here is developing a Pure Data Package manager. The basic idea of the Pure Data package manager is to deal with bundle files. We are using a zip file for each external or library as the bundle package. The bundle name will contain the library / external name and also the architecture. He is studying some software packages to base his development like deb, rpm, xip, nbm, ... Since we have different types of plugins (tcl/tk, c and pd abstraction), it can have more than one architecture. I don't know how bad is to call everything a plugin but it is how we are dealing with it. :-) The bundle also includes help files, license, readme file, a packet descriptor and installation instructions. The descriptor is a text file with several information like author, architecture, checksum, version, source path, ... We are developing a "packer" tool to help developers to pack their externals and an installation tool to add / remove plugins. Next step is to define a remote repository, a repository descriptor and a local repository. We intend to use HTTP protocol as a default repository server. Once it is done, we will develop a update tool to add repositories, list repositories' externals and add / remove plugins. I hope it will be a simple way to distribute plugins and developers will be able to provide their externals to users. Maybe it will be possible to pack every pd-extended external separately and put it in one or more repositories.
Again, since it is a final project in our computer science course, it will take some time to get it ready. I hope you can wait it a little bit more. I will keep you guys informed about it.
What do you think about it? Some suggestions?
Cheers
Flávio Schiavoni
Em 08-06-2015 19:29, IOhannes m zmölnig escreveu:
On 06/08/2015 11:55 PM, Alexandre Torres Porres wrote:
what do you mean by "monolithic distribution"?
a single zip-file containing a pd-binary (of extended flavour) and a large collection of externals.
gfmdsaf IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dear all,
I'm also working in a project with a undergrad student that maybe can be a good solution to pure data externals maintenance. He is creating a package manager to PD, like a deb packet with a repository definition and so on. It's his final essay and he needs to work alone on it. As soon as he has a first release we intend to share it here. I hope it will help to manage externals distribution.
Cheers
Flávio Schiavoni
Em 06-06-2015 13:37, Dan Wilcox escreveu:
To save extra discussion energy and *possibly* let the “cat out of the bag” let me say this: just wait a bit, something good is in the works to offer a solution to many of these problems.
I won't say anything more until the parties involved feel they are ready.
Dan Wilcox @danomatika [1] danomatika.com [2]
robotcowboy.com [3]
On Jun 6, 2015, at 11:39 AM, pd-list-request@lists.iem.at wrote:
I know I'm missing much of the technical details, but my idea is that if Pd Extended is up and running, it should be fairly easy for people to update libraries (like Fred is doing with cyclone now) and release an updated version with the updated objects... meaning we didn't have to wait for two years for a bug fix. But somehow this only makes sense in the "vanilla route".
Links:
[1] https://twitter.com/danomatika [2] http://danomatika.com [3] http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Flávio!
On 08/06/15 23:02, Flávio Schiavoni wrote:
I'm also working in a project with a undergrad student that maybe can be a good solution to pure data externals maintenance. He is creating a package manager to PD, like a deb packet with a repository definition and so on.
Sounds excellent!
It's his final essay and he needs to work alone on it.
That's a pity. So far there are now two of us collaborating on deken - IOhannes as submitted the first pull request to the project which I have merged. Would be great to add another person to get this done more quickly.
Is there no way he can satisfy the requirements of his school and also help/contribute to a collaborative project?
Even advice from the research he has done would be very welcome.
Cheers,
Chris.
-
Alexandre Torres Porres -
Chris McCormick -
Dan Wilcox -
Flávio Schiavoni -
IOhannes m zmölnig -
Roman Haefeli