Hi Hans,
On Tue, Dec 02, 2008 at 12:41:46PM -0500, Hans-Christoph Steiner wrote:
I think it's time to have a IRC meeting about this. How about
Thursday? I am trying to be in #dataflow as much as possible these
days, if anyone wants to have an impromptu discussion.
I am happy to meet on IRC, but it will have to be outside work hours for me here at GMT. Otherwise the weekend is good, but I think maybe this is something that can be solve on-list. I really think you hit the nail on the head with this paragraph:
My question remains, what is the problem we are trying to solve using
svn:externals? If it is to include code that gets built with Pd- extended, then svn:externals doesn't work well for that, just
importing releases works much better. If it is to make a centralized
place to find all Pd code, then I wonder if there is a better tool
for this, like a special section of SVN for svn:externals outside of
trunk or a wiki page.
Can you answer me this: do you see the primary function of Pd public SVN as supporting pd-extended builds? If this is the case, then we need a different part of the repository where external writers and abstraction creators can store their code/patches independent of pd-extended. The reason we need this is that whilst pd-extended is a wonderful project, and definately neccessary, not everyone in the Pd world runs it and probably some people aren't even interested in seeing their work as part of pd-extended, but they are definately interested in participating in the development community of Pd. We can't just have a wiki page as that doesn't suffice for people who want their code versioned inside the world of Pd code but aren't interested in pd-extended.
What about if SVN was the central place where Pd and related code lives, and there was a sub-place within that where pd-extended keeps its source? Most definately snapshots/tags of the former could be copied via standard svn commands into the latter to make them part of pd-extended at stable release. This would probably help with co-ordinating and versioning too. You could tell people "we are coming up for a pd-extended release, please copy your latest tags into the pd-extended folder" or do this yourself for code that you maintain. I guess the crux of what I'm saying is that I don't see the Pd svn trunk as being == to pd-extended. I see pd-extended as being a part of the ecosystem living in the svn trunk. I don't think it's fair for one project to be 100% the boss of trunk. In fact, I find it kind of annoying that once upon a time I could check out people's code from the svn and compile it independently, whereas last time I tried I couldn't do it as a bunch of environment variables weren't set and stuff. I had to hack giant complicated makefiles just to compile one simple external.
Please excuse me if I've missed anything obvious or said anything stupid, and feel free to correct me if I am misguided or wrong about the position of pd-extended in the repository. Maybe it's all just semantics. But I guess semantics are important in human communities.
Loving the broken paradise, :)
Chris.