[PD] "list foreach"?

Chris McCormick chris at mccormick.cx
Fri Oct 10 09:16:53 CEST 2014


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 at 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/#patches
> 
> 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.

-- 
http://mccormick.cx/



More information about the Pd-list mailing list