On Feb 10, 2012, at 2:14 PM, Ivica Ico Bukvic wrote:
while i appreciate your work with pd-l2ork, i think it would be great if you would be trying to get the fixes into "upstream" (where you forked from).
I did, but many fixes never got anywhere (we had this discussion a while ago), and while in the early days I spent most of my time providing additional documentation to Hans and others and making arguments on why they should be accepted which resulted in less than dozen fixes in the first year out of which only a few actually made it upstream, I am now running a fork that has 200+ improvements and fixes in approx. the same amount of time and have arrived at a rock-solid system* and have no interest in going back to a platform that may be stable on release and crash in another. Sure, I am missing a few novel features, but if the current version caters to my (perhaps somewhat specific) needs, there is no reason to go back.
FWIW, Hans has started taking some of our patches and merging it upstream (e.g. magicglass that I ported and cleaned up that has been sitting on the sourceforge database for over half a decade untouched) which is great and I would love to see the rest of it there as well. It is just that this way Hans will have to review it (which is something he would have to do anyhow), and merge it at his discretion, rather than me having to spend copious amounts of time to promote adoption of such patches and providing context that is difficult to make unless one spends some time studying the issue on their own...
*based on experiences from ongoing L2Ork rehearsals involving dozen or more networked performers.
Its great that you are maintaining your own fork. I think everyone, including you, would benefit if your changes made it upstream. That takes work in the short run, but then you don't have to maintain those anymore because they are upstream. We've been doing this with Pd-extended for many years now.
pd-l2ork/pd-extended/pd-vanilla is the perfect example of what I was talking about before. There are bugfixes and features that are currently only in pd-l2ork. There are also features and bugfixes that are only in Pd-extended 0.43. As I develop features and test them in Pd-extended, I contribute them upstream to Miller. I really try not to send raw and not tested code to Miller.
When you were submitting patches before, I spent many hours trying to get your code to work. It often didn't run at all for me, or with things like your scrolling updates, it had egregious bugs. That time I spent trying to get your code to work was time I could have spent coding. It seems that you work much better with your own fork, then you can work out the problems and test them. But you have moved your fork quite far away from were pd-vanilla and pd-extended have gone.
I think the way forward is for you to start merging in changes from pure-data.git and pd-extended.git and getting closer in sync. Then you can maintain your own fork, and easily take patches from pure-data.git and pd-extended.git and vice-versa. git makes that process a lot easier if you dive in deep, so I recommend really getting to know it.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.