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:
On Oct 9, 2014 11:31 PM, "Chris McCormick" <chris@mccormick.cx
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?
Not at all. Merely a correction of verbiage suggesting that an implementation of a desired feature in a fork is worthless.
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.
- 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.
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...
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 changes are suggested by the maintainer, address them and resubmit.
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?
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?
- Don't be a dick. I'm happy to note that the era of Pd-powered
missiles seems to be over. Good riddance!
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?
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.
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.
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.
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.
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?
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.
I never suggested that anyone should browse my code.
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"?
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...
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.
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.
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.
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...
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.
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.
Might I suggest that you read up on history before trying to preach how the open source development is done?
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 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.
It is because your agenda, and the agenda of many others,
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.
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.
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.