[PD] Problems with maintaining Pd-extended (was Mess and redundancy...)

Roman Haefeli reduzent at gmail.com
Mon Jun 8 11:04:08 CEST 2015


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





More information about the Pd-list mailing list