Sure, but we're referring to pd-vanilla.
On Oct 2, 2014, at 6:00 AM, pd-list-request@lists.iem.at wrote:
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Hi,
indeed: the code in question has been implemented several times in various external libraries, so adding it to the main binary of a pd-fork would just create an unnecessary incompatibility to vanilla core objects, but not gain anything at all.
Frank
On Thu, Oct 02, 2014 at 02:44:54PM -0400, Dan Wilcox wrote:
Ugh.
Dear list members, Do you see a problem with the development process that is implied in this thread? If so, PM me and describe (but please do not rationalize) what you think the problem is.
I can't say it will help improve anything about this (non-)development process, but it will help me retain my sanity. :)
Thanks, Jonathan
On Thursday, October 9, 2014 3:06 AM, Frank Barknecht fbar@footils.org wrote:
Hi,
indeed: the code in question has been implemented several times in various external libraries, so adding it to the main binary of a pd-fork would just create an unnecessary incompatibility to vanilla core objects, but not gain anything at all.
Frank
On Thu, Oct 02, 2014 at 02:44:54PM -0400, Dan Wilcox wrote:
On 10/9/2014 3:06 AM, Frank Barknecht wrote:
<sigh>... One could argue that those using a pd-fork would benefit, and just maybe if vanilla contributors felt compelled to do so, they could also borrow code and implement it in their version as well?
On 09/10/14 22:51, Ivica Ico Bukvic wrote:
I'm confused, is this a pull request?
In my experience the most effective way to get code merged into an open source project is as follows:
the codebase as possible to accomplish a goal.
Format your code to match the style of the codebase it is going in to.
Advocate for the patch directly with the maintainer and on the
mailing list. In the past "lots of people have requested this feature" has worked for me as a lobbying point.
If changes are suggested by the maintainer, address them and resubmit.
Accept that some patches simply won't go in. In that case you are of
course welcome to fork, or to maintain the patch in a parallel branch.
missiles seems to be over. Good riddance!
Here is someone smarter than me writing in more depth on this subject:
http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#...
Of course, Pd-l2ork is a fork and you are obviously welcome to do whatever you want. What I don't think is constructive is implying that Miller should be traipsing through the Pd-l2ork codebase and cherry picking stuff he likes out and doing the work to merge those changes cleanly into Pd. Just think about how you'd react if someone forked Pd-l2ork, made monolithic changes to the codebase, and then asked you to go through it and find stuff you might like to merge back into Pd-l2ork.
Traditionally in open source projects that isn't the way that software gets patched. Traditionally, a community of developers tries to submit patches to a maintainer and lobbies for their acceptance. We are all very busy and that seems to be the most effective way to get code merged.
Let me re-iterate again that you have every right not to do this, and your fork is an amazing piece of work, and I wish you good luck and much genuine respect for what you guys have created. *If* you or anybody else wants patches to go into Miller's Pd though, then they need to do the proper work of trying to get them in there. Our community seems to not be great at this process and I don't know why that is. I do think it's something we can fix on an individual level however.
Let me now attempt to demonstrate with [list foreach]. [1]
Tooooooooltiiiiiiiips,
Chris.
Hi Chris, That's all great advice in general. But then there's this thread in particular, where at least two perfectly capable developers chose to advocate for a trivial feature to be added to Pd rather than taking 10 minutes to implement it and make a "small, clean, self contained patch" as you suggest. Why do you think that is?
In the meantime I'll continue doing exactly the healthy development process you describe, in Pd-l2ork.
-Jonathan
On Thursday, October 9, 2014 11:18 PM, Chris McCormick chris@mccormick.cx wrote:
On 09/10/14 22:51, Ivica Ico Bukvic wrote:
<sigh>... One could argue that
those using a pd-fork would benefit, and
just maybe if vanilla contributors felt compelled to do so, they could also borrow code and implement it in their version as well?
I'm confused, is this a pull request?
In my experience the most effective way to get code merged into an open source project is as follows:
the codebase as possible to accomplish a goal.
Format your code to match the style of the codebase it is going in to.
Advocate for the patch directly with the maintainer and on the
mailing list. In the past "lots of people have requested this feature" has worked for me as a lobbying point.
If changes are suggested by the maintainer, address them and resubmit.
Accept that some patches simply won't go in. In that case you are of
course welcome to fork, or to maintain the patch in a parallel branch.
missiles seems to be over. Good riddance!
Here is someone smarter than me writing in more depth on this subject:
http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#...
Of course, Pd-l2ork is a fork and you are obviously welcome to do whatever you want. What I don't think is constructive is implying that Miller should be traipsing through the Pd-l2ork codebase and cherry picking stuff he likes out and doing the work to merge those changes cleanly into Pd. Just think about how you'd react if someone forked Pd-l2ork, made monolithic changes to the codebase, and then asked you to go through it and find stuff you might like to merge back into Pd-l2ork.
Traditionally in open source projects that isn't the way that software gets patched. Traditionally, a community of developers tries to submit patches to a maintainer and lobbies for their acceptance. We are all very busy and that seems to be the most effective way to get code merged.
Let me re-iterate again that you have every right not to do this, and your fork is an amazing piece of work, and I wish you good luck and much genuine respect for what you guys have created. *If* you or anybody else wants patches to go into Miller's Pd though, then they need to do the proper work of trying to get them in there. Our community seems to not be great at this process and I don't know why that is. I do think it's something we can fix on an individual level however.
Let me now attempt to demonstrate with [list foreach]. [1]
Tooooooooltiiiiiiiips,
Chris.
[1] http://www.youtube.com/watch?v=2Y_Jp6PxsSQ#t=19
Oh, I almost forgot-- when I suggested I'd try dev'ing it in Pd-l2ork, I was actually _dissuaded_ from doing development, for fear of creating an incompatibility.
Can you explain how to turn this community ethos into the one you imagine in your general outline-- one where we can quickly and effectively implement badly needed features like infinite undo and many others which already exist in Pd-l2ork?
-Jonathan
On Friday, October 10, 2014 12:26 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Hi Chris, That's all great advice in general. But then there's this thread in particular, where at least two perfectly capable developers chose to advocate for a trivial feature to be added to Pd rather than taking 10 minutes to implement it and make a "small, clean, self contained patch" as you suggest. Why do you think that is?
In the meantime I'll continue doing exactly the healthy development process you describe, in Pd-l2ork.
-Jonathan
On Thursday, October 9, 2014 11:18 PM, Chris McCormick chris@mccormick.cx wrote:
On 09/10/14 22:51, Ivica Ico Bukvic wrote:
<sigh>... One could argue that
those using a pd-fork would benefit, and
just maybe if vanilla contributors felt compelled to do so, they could also borrow code and implement it in their version as well?
I'm confused, is this a pull request?
In my experience the most effective way to get code merged into an open source project is as follows:
the codebase as possible to accomplish a goal.
Format your code to match the style of the codebase it is going in to.
Advocate for the patch directly with the maintainer and on the
mailing list. In the past "lots of people have requested this feature" has worked for me as a lobbying point.
If changes are suggested by the maintainer, address them and resubmit.
Accept that some patches simply won't go in. In that case you are of
course welcome to fork, or to maintain the patch in a parallel branch.
missiles seems to be over. Good riddance!
Here is someone smarter than me writing in more depth on this subject:
http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#...
Of course, Pd-l2ork is a fork and you are obviously welcome to do whatever you want. What I don't think is constructive is implying that Miller should be traipsing through the Pd-l2ork codebase and cherry picking stuff he likes out and doing the work to merge those changes cleanly into Pd. Just think about how you'd react if someone forked Pd-l2ork, made monolithic changes to the codebase, and then asked you to go through it and find stuff you might like to merge back into Pd-l2ork.
Traditionally in open source projects that isn't the way that software gets patched. Traditionally, a community of developers tries to submit patches to a maintainer and lobbies for their acceptance. We are all very busy and that seems to be the most effective way to get code merged.
Let me re-iterate again that you have every right not to do this, and your fork is an amazing piece of work, and I wish you good luck and much genuine respect for what you guys have created. *If* you or anybody else wants patches to go into Miller's Pd though, then they need to do the proper work of trying to get them in there. Our community seems to not be great at this process and I don't know why that is. I do think it's something we can fix on an individual level however.
Let me now attempt to demonstrate with [list foreach]. [1]
Tooooooooltiiiiiiiips,
Chris.
[1] http://www.youtube.com/watch?v=2Y_Jp6PxsSQ#t=19
On 10/10/14 12:29, Jonathan Wilkes via Pd-list wrote:
Yep, noted. Seems pretty crazy from your perspective, right? I think I understand why, and I would like to hear your thoughts on why two people would dissuade you from doing the development of "list foreach" in Pd-l2ork. What was their motivation?
Infinite-undo is particularly hairy, so that's a good edge-case to examine.
We have seen a change as large and unweildy (maybe even larger and
unweildy-er) as infinite-undo go into Miller's version of Pd before.
Hans' tcl/GUI refactor work was large and disruptive and changed the
codebase in many places. So how did Hans manage to get it into Pd? Well,
I asked him that a while back, and if memory serves it was a months long
effort continuously submitting small patches against Pd HEAD and
emailing Miller directly and politely to advocate for those patches.
(ref: git log --author hans
) As painful as that sounds, it is the
customary way to get code into most Free Software projects, and more
importantly, it was what worked. I am infinitely thankful to Hans that
he took the time to do that work and submit it correctly because we all
get a better piece of software for it.
I am also of course infinitely thankful to Miller for creating such a gigantic and amazing work and letting us jerks at it with no strings attached. Can we really ask more of a person?
Most changes to Pd are not going to be as large and hairy as infinite undo, or gui refactors. Most changes are little things and those ones are ripe for improving our process. I humbly submit that what I outlined, for most smaller changes, will get more code into Pd than other processes.
You may or may not be interested in that, and that is your prerogative.
Cheers,
Chris.
On 10/10/14 12:26, Jonathan Wilkes wrote:
My guess is that we all have busy lives outside Pd.
My first instinct was to do work that I will get paid for this morning instead, but then I realised this may be an opportunity to change things for the better in our community, and therefore for myself. Selfish!
Now my daughter will get a lump of coal for xmas and I will have to tell her that it is because I spent all my time arguing with people on my computer instead of earning money.
In the meantime I'll continue doing exactly the healthy development process you describe, in Pd-l2ork.
Sounds good! Nice one.
I realise that following the same process with Miller's Pd is more difficult because Miller is more conservative about what he accepts into Pd than Ico, and you have not built the same working relationship with him. My hunch is that a greater number of users will benefit if you try to follow the same process on Miller's Pd as well.
I am not trying to coerce you.
Cheers,
Chris.
Hi Chris, I've used the same development process for Pd-extended and Vanilla as I have with Pd-l2ork. It is pretty close to the general outline you gave in this thread. There is no difference in working relationship-- I send patches, write emails, test changes, say snarky things, etc.
But I'll happily work with you to improve Pd Vanilla and get as many improvements as possible from Pd-l2ork ported into it. Which improvements you'd like to port.
-Jonathan
On Friday, October 10, 2014 1:39 AM, Chris McCormick chris@mccormick.cx wrote:
On 10/10/14 12:26, Jonathan Wilkes wrote:
10
minutes to implement it and make a "small, clean, self contained patch" as you suggest. Why do you think that is?
My guess is that we all have busy lives outside Pd.
My first instinct was to do work that I will get paid for this morning instead, but then I realised this may be an opportunity to change things for the better in our community, and therefore for myself. Selfish!
Now my daughter will get a lump of coal for xmas and I will have to tell her that it is because I spent all my time arguing with people on my computer instead of earning money.
In the meantime I'll continue doing exactly the healthy development process you describe, in Pd-l2ork.
Sounds good! Nice one.
I realise that following the same process with Miller's Pd is more difficult because Miller is more conservative about what he accepts into Pd than Ico, and you have not built the same working relationship with him. My hunch is that a greater number of users will benefit if you try to follow the same process on Miller's Pd as well.
I am not trying to coerce you.
Cheers,
Chris.
Oops, I mean: which improvements would you like to port?
-Jonathan
On Friday, October 10, 2014 3:14 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Hi Chris, I've used the same development process for Pd-extended and Vanilla as I have with Pd-l2ork. It is pretty close to the general outline you gave in this thread. There is no difference in working relationship-- I send patches, write emails, test changes, say snarky things, etc.
But I'll happily work with you to improve Pd Vanilla and get as many improvements as possible from Pd-l2ork ported into it. Which improvements you'd like to port.
-Jonathan
On Friday, October 10, 2014 1:39 AM, Chris McCormick chris@mccormick.cx wrote:
On 10/10/14 12:26, Jonathan Wilkes wrote:
10
minutes to implement it and make a "small, clean, self contained patch" as you suggest. Why do you think that is?
My guess is that we all have busy lives outside Pd.
My first instinct was to do work that I will get paid for this morning instead, but then I realised this may be an opportunity to change things for the better in our community, and therefore for myself. Selfish!
Now my daughter will get a lump of coal for xmas and I will have to tell her that it is because I spent all my time arguing with people on my computer instead of earning money.
In the meantime I'll continue doing exactly the healthy development process you describe, in Pd-l2ork.
Sounds good! Nice one.
I realise that following the same process with Miller's Pd is more difficult because Miller is more conservative about what he accepts into Pd than Ico, and you have not built the same working relationship with him. My hunch is that a greater number of users will benefit if you try to follow the same process on Miller's Pd as well.
I am not trying to coerce you.
Cheers,
Chris.
Hi Jonathan,
I am beginning to think that this is the part of tonight's routine where I am made to eat my words. :)
On 10/10/14 15:15, Jonathan Wilkes wrote:
I really appreciate this response and sentiment, thanks.
I must admit to ignorance again as to what features could go from Pd-l2ork into Pd. This is because I only know about Pd-l2ork from what Ico showed me at VT - SVG rendering, k-12 application, and infinite undo. I am probably forgetting other things he showed me - it was quite a demo!
The only concrete one that seems obvious to me is infinite undo, and it seems like there is at least some desire from Miller's side for this feature from what Ico said. It also seems like creating a branch of Miller's Pd with the Pd-l2ork patches applying cleanly would be a mammoth task and I can't ask you to do that because I don't have time or skills to do it myself. If you did this of course, you would be my absolute Pd hero.
Miller, what do you think about infinite undo?
In the future with things like "list foreach" do you think there is a middle ground we could follow where we implement it in a way that might go into Miller's Pd as well as into Pd-l2ork and then actually try to solicit feedback from Miller?
In some situations I know this may involve emailing him and the list first to try to reach a consensus on the implementation before starting. I also know that Miller sometimes gets handwavey in those situations because he hasn't figured out the ultimate design yet. In my experience, waiting for the ultimate design is quite often worth it. For example, I would have implemented the tosymbol/fromsymbol stuff completely differently but it's now obvious to me that Miller's implementation kicks the crap out of anything I'd thought of in terms of flexibility and wider applicability.
I may again be being ignorant but it I don't remember any kind of submitting-back-to-Pd process with "list cat" so I assume it's not something that generally happens right now due to (understandable) frustration with the process etc.
I feel like it would be great for everyone involved if we could keep more compatibility with these base objects and that is my agenda in advocating for it. I also understand you guys might be totally disinterested in doing that work (Ico's frustration case in point), and it might hold you back too much, and that's ok too. I need to push for it though because I think it's of great benefit to many users (including myself) if we can get it right.
Cheers,
Chris.
The main reason Pd-l2ork is not benefiting more users is because there aren't binaries/bundles for OSX and Windows. There's a Pd-l2ork app I made for OSX some time back that has a small selection of libs I compiled with it, but I don't think there will be any more work on more platforms until we complete the move to Qt for the GUI.
Btw-- there are many facets of the development process where waiting for an ultimate design is counterproductive. If you want to try devoting energy to Pd Vanilla, start with the "Tidy Up" function. It is self-contained and a less-than-perfect design won't affect anything else in Pd. Moreover, nearly anything you implement will be better than what's currently there. (There's an improved "Tidy Up" in Pd-l2ork, btw.)
If instead you wait for an ultimate design, the users lose because they get zero productivity increase while you/they wait.
-Jonathan
On Friday, October 10, 2014 4:06 AM, Chris McCormick chris@mccormick.cx wrote:
Hi Jonathan,
I am beginning to think that this is the part of tonight's routine where I am made to eat my words. :)
On 10/10/14 15:15, Jonathan Wilkes wrote:
I really appreciate this response and sentiment, thanks.
I must admit to ignorance again as to what features could go from Pd-l2ork into Pd. This is because I only know about Pd-l2ork from what Ico showed me at VT - SVG rendering, k-12 application, and infinite undo. I am probably forgetting other things he showed me - it was quite a demo!
The only concrete one that seems obvious to me is infinite undo, and it seems like there is at least some desire from Miller's side for this feature from what Ico said. It also seems like creating a branch of Miller's Pd with the Pd-l2ork patches applying cleanly would be a mammoth task and I can't ask you to do that because I don't have time or skills to do it myself. If you did this of course, you would be my absolute Pd hero.
Miller, what do you think about infinite undo?
In the future with things like "list foreach" do you think there is a middle ground we could follow where we implement it in a way that might go into Miller's Pd as well as into Pd-l2ork and then actually try to solicit feedback from Miller?
In some situations I know this may involve emailing him and the list first to try to reach a consensus on the implementation before starting. I also know that Miller sometimes gets handwavey in those situations because he hasn't figured out the ultimate design yet. In my experience, waiting for the ultimate design is quite often worth it. For example, I would have implemented the tosymbol/fromsymbol stuff completely differently but it's now obvious to me that Miller's implementation kicks the crap out of anything I'd thought of in terms of flexibility and wider applicability.
I may again be being ignorant but it I don't remember any kind of submitting-back-to-Pd process with "list cat" so I assume it's not something that generally happens right now due to (understandable) frustration with the process etc.
I feel like it would be great for everyone involved if we could keep more compatibility with these base objects and that is my agenda in advocating for it. I also understand you guys might be totally disinterested in doing that work (Ico's frustration case in point), and it might hold you back too much, and that's ok too. I need to push for it though because I think it's of great benefit to many users (including myself) if we can get it right.
Cheers,
Chris.
Indeed, the 'tidy up" function is a good example of what I could adapt from llork into vanilla. (Another, major thing I'm planning to adopt is the stacking order and infinite undo feature(s) ). I have to say that's much more interesting and important than list foreach (which I think neds to be redesigned somewhat).
Not doing this right now because I'm 100% duty cycle teaching at the moment.
cheers M
On Fri, Oct 10, 2014 at 08:23:44AM -0700, Jonathan Wilkes via Pd-list wrote:
One last clarification-- I'm saying that I use the development process Chris outlines to do work on all flavors. What frustrated me on this thread is the idea of a process where the community suggests or votes for certain features, and Miller adds them. That model is too conservative-- it leads to fewer developers actually looking at the core code and (potentially) improving things.
-Jonathan
On Friday, October 10, 2014 3:14 AM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
Hi Chris, I've used the same development process for Pd-extended and Vanilla as I have with Pd-l2ork. It is pretty close to the general outline you gave in this thread. There is no difference in working relationship-- I send patches, write emails, test changes, say snarky things, etc.
But I'll happily work with you to improve Pd Vanilla and get as many improvements as possible from Pd-l2ork ported into it. Which improvements you'd like to port.
-Jonathan
On Friday, October 10, 2014 1:39 AM, Chris McCormick chris@mccormick.cx wrote:
On 10/10/14 12:26, Jonathan Wilkes wrote:
10
minutes to implement it and make a "small, clean, self contained patch" as you suggest. Why do you think that is?
My guess is that we all have busy lives outside Pd.
My first instinct was to do work that I will get paid for this morning instead, but then I realised this may be an opportunity to change things for the better in our community, and therefore for myself. Selfish!
Now my daughter will get a lump of coal for xmas and I will have to tell her that it is because I spent all my time arguing with people on my computer instead of earning money.
In the meantime I'll continue doing exactly the healthy development process you describe, in Pd-l2ork.
Sounds good! Nice one.
I realise that following the same process with Miller's Pd is more difficult because Miller is more conservative about what he accepts into Pd than Ico, and you have not built the same working relationship with him. My hunch is that a greater number of users will benefit if you try to follow the same process on Miller's Pd as well.
I am not trying to coerce you.
Cheers,
Chris.
On 10/10/14 15:48, Jonathan Wilkes wrote:
Completely agree that would be too conservative. I don't think that's how it works now either because other developer's patches do go into Pd. For non-developer users I guess they have no other choice of course.
I am sorry if it sounded like I was telling you to do something that you are already doing. That would be pretty annoying.
I think that for some features there is a case to be made for consensus before development with so many actors and variants in the mix, but only on features that we all think make sense to be shared by all flavours of Pd. I think "list foreach" is a classic example of that type of thing where it probably wouldn't be good for users if we had different versions of this core object implemented.
Can you think of any others that are in Pd-l2ork right now that you feel like probably should be in all versions of Pd?
I don't think it's reasonable for Pd-l2ork developers to feel like they have to check every change with the community or with Miller. Happily, that's not the case now and as a result you guys have been able to innovate in very interesting directions.
There's probably a balance in there somewhere that lets users of Pd-l2ork and users of Pd, extended, and libpd all win.
Cheers,
Chris.
The only case to be made is for development, with the imperative, "develop." It's quite trivial to post a message to the console for a new class that says "version 0.1" and/or "not stable yet" and/or "send feedback to foo@bar". It's even possible to do that for methods of a class, which is what I've done with pdinfo/classinfo/canvasinfo/objectinfo.
If you have access to a Linux box, I highly recommend downloading the source for Pd-l2ork from git, compiling, and giving it a try. There are too many generally-applicable features to list here, but here's what comes to mind: infinite undo, object z-order control from "Edit" menu and right-click canvas menu, colors other than black for garray trace, better prefs dialog, presets that handle abstractions without the need for $0, resize anchor for iemguis and red gop rect, hyperlinked errors in the console, Max-style [trigger b 42], [select] right inlet can receive symbol or float, PDDP documentation, _natural_ _language_ _search_ _engine_, cross-referenced tutorials, hyperlinks, sending a single "canvas move" instruction to the gui when displacing a selection of objects, not deleting/redrawing the entire garray when the user displaces it, (some) standard key bindings for editing inside an object box, multi-connect logic, a better "Tidy Up", displace anchor for iemgui labels, objects for canvas/object/class/pd-instance introspection...
-Jonathan
On Friday, October 10, 2014 4:19 AM, Chris McCormick chris@mccormick.cx wrote:
On 10/10/14 15:48, Jonathan Wilkes wrote:
Completely agree that would be too conservative. I don't think that's how it works now either because other developer's patches do go into Pd. For non-developer users I guess they have no other choice of course.
I am sorry if it sounded like I was telling you to do something that you are already doing. That would be pretty annoying.
I think that for some features there is a case to be made for consensus before development with so many actors and variants in the mix, but only on features that we all think make sense to be shared by all flavours of Pd. I think "list foreach" is a classic example of that type of thing where it probably wouldn't be good for users if we had different versions of this core object implemented.
Can you think of any others that are in Pd-l2ork right now that you feel like probably should be in all versions of Pd?
I don't think it's reasonable for Pd-l2ork developers to feel like they have to check every change with the community or with Miller. Happily, that's not the case now and as a result you guys have been able to innovate in very interesting directions.
There's probably a balance in there somewhere that lets users of Pd-l2ork and users of Pd, extended, and libpd all win.
Cheers,
Chris.
Oh dear...
On Oct 9, 2014 11:31 PM, "Chris McCormick" chris@mccormick.cx wrote:
Not at all. Merely a correction of verbiage suggesting that an implementation of a desired feature in a fork is worthless.
Check.
Check.
Houston, we got problem. I did this before I forked. And when I have to spend 4x time advocating something than what it took me to build it (even when building it was time consuming ordeal in and of itself), and then still not get it merged, I am sorry but life is too short for such pointless banter. I will much rather code instead and produce 4 more patches. Worse yet, many of the proposed fixes afterwards never actually got fixed in any of the possible alternative ways...
What if suggestions make no sense or are so off-topic that it is pointless or incredibly time consuming to even discuss them? Or better yet, there is no response and your work depends on those changes being in the code?
I did, and hence the fork.
Seriously? So, by suggesting that a fork user patching a fork of their preference is not worthless, as suggested by Frank, in part also because it may trickle back into upstream is being a dick? Or were you referring to Frank's remark?
Here is someone smarter than me writing in more depth on this subject:
http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#...
Might I suggest reading up on history of my contributions before playing a jump-to-conclusions game? That may help you imply less and understand more.
Of course, Pd-l2ork is a fork and you are obviously welcome to do whatever you want. What I don't think is constructive is implying that
What I don't think is constructive is implying what you think I was implying.
I never suggested that anyone should browse my code. And even in the case someone did, there is this thing called git, and pd-l2ork's typically contains patches that are for the most part manageable. And as I have done before on this list I typically pointed out a link to the relevant fix. Now, as code base diverges more and more over time such fixes will continue to make less and less sense, but that is a completely different matter...
BTW, Miller did mention last time we spoke that he would like to borrow/rewrite preset and undo mechanisms, but this would be a mega patch to begin with, and I have no interest in providing such a patch knowing how unlikely it is for it to be merged. So, you have a choice, stick with whatever makes your life easier, and then accept the limitations of your choice.
As for your question, I don't care if you or anyone else forks pd-l2ork. It's been already done and re-merged many times. I also would not call anyone a dick or their contribution worthless for merely suggesting that they may have a patch to offer upstream that I could review at my own discretion and choose to merge or not, and particularly if I did not know much about the history of said choices...
Might I suggest that you read up on history before trying to preach how the open source development is done?
It is because your agenda, and the agenda of many others, including Miller, differ vastly from each other. Miller, for instance wants to do everything he can to keep even the oldest of patches running--a formidable task. Yet, the same goal seriously impedes development and even fixing of most trivial bugs because there's is a good chunk of legacy code even Miller thinks shouldn't be there, e.g. iemgui objects, and yet to fulfill his mission he has no choice but to keep it as-is. Some would argue this is one potential definition of a stalemate. OTOH, there are some of us who are less concerned with legacy and more interested in faster development, which is also the main driving force behind pd-l2ork.
A truly disappointing thread ...
Hi Ico,
Most important thing first: I do not think you are a dick, or that you are being a dick, and I was not calling you a dick. I am tremendously sorry that my email came across that way.
I re-edited that email several times to try to make sure that nothing I was saying was inflammatory or accusatory and try to keep it as a set of *positive actions* we can take as a community to improve things. Of course I clearly failed at that, and I am sorry.
Please accept my sincerest apologies for your offense. I mean that 100% genuinely and I would like to buy you dinner next time we are in the same neck of the woods as a proper apology.
Additionally, no single sentence I have written below is intended as sarcasm. Please take what I have written exactly as it is written with no hidden implications, insinuations, etc.
*Hazmat suits deployed* ;)
On 10/10/14 13:52, Ivica Bukvic wrote:
My reading of the situation is that Frank and Dan and others would rather see the feature go into *all* versions of Pure Data in a compatible way than into just one in a way that may cause incompatibility for users.
I completely understand that is a difficult and annoying task.
I completely understand the reasons that Pd-l2ork exists.
I appreciate what you guys have created and I think it is wonderful.
You are obviously allowed to forge ahead and implement "foreach" however you like in Pd-l2ork.
Others are allowed to express a concern that doing so may cause future incompatibility.
Totally understand your frustration. I have also had patches rejected and silently dropped on all kinds of FLOSS projects. I am right there with you. Sometimes when you want to move quickly you need to fork and forge ahead and that is your prerogative.
It's obvious that some of the fantastic innovations (SVG guis) in Pd-l2ork would probably never go into Pd and I think for that reason it makes a lot of sense to have a fork.
I guess it's also obvious that having a fork does not exclude patches crossing from one version to the other, and I remember you told me that you merge many of the Pd core patches into your fork, which is fantastic for users like myself.
If you feel that is the case then it makes sense to fork, as you did. All good.
Did this happen for every patch you submitted to Pd? Did any patches you submitted go in? Please excuse my ignorance in this regard.
Do you think it would be worth trying again with some patches so that the community benefits, or do you think that would be a waste of your time?
No, that is not being a dick. You were not being a dick, and I did not mean to imply in my email that you were being a dick.
"Pd-powered missiles" refers directly to flamewars between Mathieu Bouchard and Yves Degoyon.
Frank's words were "not gain anything at all" which I agree does sound a lot like "worthless" so perhaps he might better have written "not gain anything at all for the majority of Pure Data users who don't currently use Pd-l2ork," which I think might have been more accurate.
This "don't be a dick" point was a general point of advice about submitting patches to open source projects. I was not saying that anybody was being a dick, but that *not* being a dick is generally a good idea if you are trying to get code into a project.
I'm sorry that you felt it was directed at you as I did not mean that.
You are completely correct in assuming that I am ignorant about your history of contributions, except in so far as it is obvious to everybody that Pd-l2ork is a monumental work of software that you have done a great deal of work on. I apologise for speaking from ignorance, and you are free to completely ignore my ideas, especially since you say that you have already tried them and they did not work for you.
The point of my email was to say what has worked for me in the past and what might work for other people in the future who want to get code into Pd.
You wrote: "if vanilla contributors felt compelled to do so, they could also borrow code and implement it in their version as well".
I think you are saying that vanilla contributors should go into the Pd-l2ork codebase and find and pull out the bits/commits that they might like.
Let me know if my reading is not correct here.
Actually, reading that again, it's more like vanilla contributors *could* go into the codebase and pull out bits. So I am putting an unfortunate spin on it, sorry.
The point of my email is that this strategy won't work for getting code into Miller's Pure Data. It seems like you have already tried the alternate strategy I advocate and it did not work for you either, and so the only option left to you is to forge onward without attempting to submit patches to Miller. I understand that, and I understand your frustration at being in that situation.
Let me also make an extra apology here - "I'm confused, is this a pull request?" is clearly baiting you. I should not have done that. For some misguided reason I thought it would be amusing. I'm sorry about that.
As a thought experiment - do you think the strategy I outline would have worked for "list foreach" had you or Jonathan attempted it?
Am I reading this incorrectly then: "if vanilla contributors felt compelled to do so, they could also borrow code and implement it in their version as well"?
Point taken that Pd-l2ork has a git repository and that you typically point out a link to the relevant fix. That's great, thanks for doing that. I'm sorry I was ignorant about your having done that in the past. My memory is pretty awful!
One of the points in that Red Hat document is that patches for merging should work against the current HEAD of the project to be merged into. So if you genuinely did want a patch to go into Miller's Pd, then that's probably a good thing to do.
I completely understand that your previous frustration might not lead you to even want to do that. It's a time consuming and difficult task. 100% ok and your right to not want to do that.
Yep, gotcha. I think in my previous email I was saying that what Hans did with the GUI was a huge amount of work and time consuming. I am super grateful to him for doing that. I realise that breaking the undo thing up into smaller more digestible commits on a branch against Pd would be a colossal task and that you are very busy.
The only think I can guarantee is that the task would not be thankless per se. There would be much thanks, and also rejoicing.
I am sorry for my ignorance about your past history of submitting patches to Pure Data, and about Pd-l2ork forks that you have merged back in.
I agree with Frank that a patch to the core functionality of "list foreach" may not benefit the majority of Pure Data users at this point in time. I hope you can see why that may be the case.
I do not think you are a dick.
My apologies again if I was preaching. My intention was 100% genuine, and that is to help us get more good things into Pd.
You are right that I am pretty ignorant about the history and specifically your own history of submitting patches.
Let me be clear about my agenda. My agenda is to have more good code go into the version of Pure Data that I use for making music and software. My agenda is to have my music and software be as widely deployable to as many users on as many platforms as possible. I don't think I have any other agenda with regards to Pure Data.
including Miller, differ vastly from each other.
That is typical in open source software projects. The way we make the world better is by finding common ground - vectors pointing in the same direction, and improving the things that we work on together.
It's opt-in and it works best when those vectors are aligned. The billions of person-hours of software development on open source projects are testament to the fact that this alignment happens remarkably often.
I think that's a great and accurate characterisation of the situation. It's very illuminating to read this crystalised, thanks.
A truly disappointing thread ...
I am sorry you feel disappointed Ico! I hope you will feel better about this discussion after reading my email. Most of all I hope I have not made things worse.
Cheers,
Chris.
On Fri, Oct 10, 2014 at 01:52:00AM -0400, Ivica Bukvic wrote:
Something that always impressed me from the Perl community was Larry's idea of an Apocalypse for moving from 5 to 6
When a community gets 5+ years advanced notice of moving to a new chapter the stalemate issues have a mechanism to dissolve. A major _planned_ landmark/milestone also acts as a rallying point for debate and concrete decision making. The Perl5/6 split and rendezvous seems like a mature, farsighted way to handle modernising a codebase with complex community and legacy concerns.
best, Andy