[PD-dev] report: pd meeting @ lac2

Hans-Christoph Steiner hans at eds.org
Mon May 31 22:37:28 CEST 2004


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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5422 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20040531/e132c154/attachment.bin>


More information about the Pd-dev mailing list