<p dir="ltr">Oh dear...</p>
<p dir="ltr">On Oct 9, 2014 11:31 PM, "Chris McCormick" <<a href="mailto:chris@mccormick.cx">chris@mccormick.cx</a>> wrote:<br>
><br>
> On 09/10/14 22:51, Ivica Ico Bukvic wrote:<br>
> > <sigh>... One could argue that those using a pd-fork would benefit, and<br>
> > just maybe if vanilla contributors felt compelled to do so, they could<br>
> > also borrow code and implement it in their version as well?<br>
><br>
> I'm confused, is this a pull request?</p>
<p dir="ltr">Not at all. Merely a correction of verbiage suggesting that an implementation of a desired feature in a fork is worthless.</p>
<p dir="ltr">><br>
> In my experience the most effective way to get code merged into an open<br>
> source project is as follows:<br>
><br>
>  * Make a small, clean, self contained patch that changes as little of<br>
> the codebase as possible to accomplish a goal.</p>
<p dir="ltr">Check.</p>
<p dir="ltr">><br>
>  * Format your code to match the style of the codebase it is going in to.<br>
></p>
<p dir="ltr">Check.</p>
<p dir="ltr">>  * Advocate for the patch directly with the maintainer and on the<br>
> mailing list. In the past "lots of people have requested this feature"<br>
> has worked for me as a lobbying point.</p>
<p dir="ltr">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...</p>
<p dir="ltr">><br>
>  * If changes are suggested by the maintainer, address them and resubmit.</p>
<p dir="ltr">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?</p>
<p dir="ltr">><br>
>  * Accept that some patches simply won't go in. In that case you are of<br>
> course welcome to fork, or to maintain the patch in a parallel branch.</p>
<p dir="ltr">I did, and hence the fork.</p>
<p dir="ltr">><br>
>  * Don't be a dick. I'm happy to note that the era of Pd-powered<br>
> missiles seems to be over. Good riddance!</p>
<p dir="ltr">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?</p>
<p dir="ltr">><br>
> Here is someone smarter than me writing in more depth on this subject:<br>
><br>
> <a href="http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#patches">http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#patches</a></p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
> Of course, Pd-l2ork is a fork and you are obviously welcome to do<br>
> whatever you want. What I don't think is constructive is implying that</p>
<p dir="ltr">What I don't think is constructive is implying what you think I was implying.</p>
<p dir="ltr">> Miller should be traipsing through the Pd-l2ork codebase and cherry<br>
> picking stuff he likes out and doing the work to merge those changes<br>
> cleanly into Pd. Just think about how you'd react if someone forked<br>
> Pd-l2ork, made monolithic changes to the codebase, and then asked you to<br>
> go through it and find stuff you might like to merge back into Pd-l2ork.</p>
<p dir="ltr">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...</p>
<p dir="ltr">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.</p>
<p dir="ltr">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...</p>
<p dir="ltr">><br>
> Traditionally in open source projects that isn't the way that software<br>
> gets patched. Traditionally, a community of developers tries to submit<br>
> patches to a maintainer and lobbies for their acceptance. We are all<br>
> very busy and that seems to be the most effective way to get code merged.</p>
<p dir="ltr">Might I suggest that you read up on history before trying to preach how the open source development is done?</p>
<p dir="ltr">><br>
> Let me re-iterate again that you have every right not to do this, and<br>
> your fork is an amazing piece of work, and I wish you good luck and much<br>
> genuine respect for what you guys have created. *If* you or anybody else<br>
> wants patches to go into Miller's Pd though, then they need to do the<br>
> proper work of trying to get them in there. Our community seems to not<br>
> be great at this process and I don't know why that is. I do think it's<br>
> something we can fix on an individual level however.</p>
<p dir="ltr">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.</p>
<p dir="ltr">A truly disappointing thread ...</p>
<p dir="ltr">><br>
> Let me now attempt to demonstrate with [list foreach]. [1]<br>
><br>
> Tooooooooltiiiiiiiips,<br>
><br>
> Chris.<br>
><br>
> [1] <a href="http://www.youtube.com/watch?v=2Y_Jp6PxsSQ#t=19">http://www.youtube.com/watch?v=2Y_Jp6PxsSQ#t=19</a><br>
><br>
> --<br>
> <a href="http://mccormick.cx/">http://mccormick.cx/</a><br>
</p>