Hi pd-list, hi pd-dev-list, hi Miller,
during the Linux Audio Conference 2 at the ZKM in Karlsruhe, we organized a small Pd meeting to informally discuss several topics concerning the developement of Pd and surrounding projects.
External Development ---------------------
First of all, there was the suggestion to create sets of externals, that are used to destinguish between kinds of externals, and to provide some kind of quality control for externals. This is supposed to make life easier for users to figure out, what the externals are doing, if they can rely on them (rock-solid vs. experimental externals) and also could make package releases easier, because not every external collection might stable or new at the same time. Further it might then be useful to get into concrete release cycles for such sets of externals (maybe including "deadlines", hoho!).
It was also suggested to introduce a namespace for externals and/or abstractions to prevent the problem caused by objects with the same name (e.g. different "counter"s are provided in several libraries, but a package can hold only one). We also discussed moving the CVS to another server to improve the CVS access. IWRC, the IEM and Mathieu offered to set up a server, or maybe Miller can offer one at the UCSD. A reorganisation of the externals could be done when moving to another CVS server. A switch from CVS to subversion should be considered.
Pd Development ---------------
A second thing we discussed was the actual Pd development. The possible branching between Pd and IMPd and the differences between Miller's Pd and the devel branch on CVS might lead to problems for example for developers of externals but also for users ("What Pd will I need to achieve this task/run that external?"). We should discuss consequences of this openly with everyone involved.
What definitely should improve, is the coordination of the development. This could improve by more actively using the pd-dev list to discuss further development, to maybe set up some kind of roadmap that we divide into tasks assigned to certain people etc.
Concerning the CVS, we suggested that the MAIN branch could be a stable branch that could form a base for packages (similar to devel_0_37 is now). The actual development branch should be the unstable/experimental branch. Patches to the development branch can be merged to the MAIN branch when they are reported to be stable on all supported platforms.
The main CVS branch already follows the upstream MSP version: it's not as experimental as IMPd, and regularily merges Miller's changes back in. This is a tedious work, that could be made much easier, if Miller's version and all changes there would be done directly in the CVS. Question to Miller: Would it be possible that you use the CVS for developments, too? This would improve the communication and coordination with the other developers.
Pd is a pretty good piece of software, but it still has a way to go to 1.0. We should all try to combine our efforts to improve the development.
Sitting at the dinner table were:
Frank Barknecht Tim Blechmann Thomas Charbonnel Guenter Geiger Thomas Grill Kjetil Matheussen
Thanks for the report, its quite good. I have a couple comments to add:
On May 31, 2004, at 2:15 PM, Tim Blechmann wrote:
Hi pd-list, hi pd-dev-list, hi Miller,
during the Linux Audio Conference 2 at the ZKM in Karlsruhe, we organized a small Pd meeting to informally discuss several topics concerning the developement of Pd and surrounding projects.
External Development
First of all, there was the suggestion to create sets of externals, that are used to destinguish between kinds of externals, and to provide some kind of quality control for externals. This is supposed to make life easier for users to figure out, what the externals are doing, if they can rely on them (rock-solid vs. experimental externals) and also could make package releases easier, because not every external collection might stable or new at the same time. Further it might then be useful to get into concrete release cycles for such sets of externals (maybe including "deadlines", hoho!).
It was also suggested to introduce a namespace for externals and/or abstractions to prevent the problem caused by objects with the same name (e.g. different "counter"s are provided in several libraries, but a package can hold only one). We also discussed moving the CVS to another server to improve the CVS access. IWRC, the IEM and Mathieu offered to set up a server, or maybe Miller can offer one at the UCSD. A reorganisation of the externals could be done when moving to another CVS server. A switch from CVS to subversion should be considered.
I think this is a good idea, but will take lots of work to accomplish, and there are a couple steps that would smooth the process. First is having a clean, well-organized layout. Second is having decent developer docs, so that developers know how to incorporate there code into these systems that we devise.
Also, I have been expanding along the lines that Dave Sabine laid out, and created a bunch of "all_about_*" help patches which are overviews of a certain topic, which examples of different ways of doing it, as well as links to all of the related objects. Look in the CVS for some new ones in varying levels of completion: all_about_cyclone, all_about_data_structures, all_about_data_types, all_about_haptics, all_about_hid, all_about_looping, all_about_lists_vs_anythings, all_about_symbol_construction. I think this will aid the above goals.
Pd Development
A second thing we discussed was the actual Pd development. The possible branching between Pd and IMPd and the differences between Miller's Pd and the devel branch on CVS might lead to problems for example for developers of externals but also for users ("What Pd will I need to achieve this task/run that external?"). We should discuss consequences of this openly with everyone involved.
What definitely should improve, is the coordination of the development. This could improve by more actively using the pd-dev list to discuss further development, to maybe set up some kind of roadmap that we divide into tasks assigned to certain people etc.
Concerning the CVS, we suggested that the MAIN branch could be a stable branch that could form a base for packages (similar to devel_0_37 is now). The actual development branch should be the unstable/experimental branch. Patches to the development branch can be merged to the MAIN branch when they are reported to be stable on all supported platforms.
The main CVS branch already follows the upstream MSP version: it's not as experimental as IMPd, and regularily merges Miller's changes back in. This is a tedious work, that could be made much easier, if Miller's version and all changes there would be done directly in the CVS. Question to Miller: Would it be possible that you use the CVS for developments, too? This would improve the communication and coordination with the other developers.
I also think that getting all of the main development into a unified CVS repository, where ever that might be, is high priority. A lot of good code is getting lost in the fray because it is very hard and time intensive to keep thing organized given the current situation. Just having the core Pd work done the CVS, with only Miller having write permissions would go a long way. Then that would help to smooth out the social issues of moving towards working together on the core. I for one have stopped working on the core because its such a pain to deal with the current situation. I am waiting until its more organized, and I don't have to spend lots of time dealing with patches.
.hc
Pd is a pretty good piece of software, but it still has a way to go to 1.0. We should all try to combine our efforts to improve the development.
Sitting at the dinner table were:
Frank Barknecht Tim Blechmann Thomas Charbonnel Guenter Geiger Thomas Grill Kjetil Matheussen
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
-
Hans-Christoph Steiner -
Tim Blechmann