[PD] "list foreach"?

Ivica Bukvic ico at vt.edu
Fri Oct 10 07:52:00 CEST 2014


Oh dear...

On Oct 9, 2014 11:31 PM, "Chris McCormick" <chris at 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?

Not at all. Merely a correction of verbiage suggesting that an
implementation of a desired feature in a fork is worthless.

>
> In my experience the most effective way to get code merged into an open
> source project is as follows:
>
>  * Make a small, clean, self contained patch that changes as little of
> the codebase as possible to accomplish a goal.

Check.

>
>  * Format your code to match the style of the codebase it is going in to.
>

Check.

>  * 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...

>
>  * 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?

>
>  * 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.

I did, and hence the fork.

>
>  * 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?

>
> 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.

>
> 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.

> 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. 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...

>
> 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?

>
> 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, 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 ...

>
> Let me now attempt to demonstrate with [list foreach]. [1]
>
> Tooooooooltiiiiiiiips,
>
> Chris.
>
> [1] http://www.youtube.com/watch?v=2Y_Jp6PxsSQ#t=19
>
> --
> http://mccormick.cx/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141010/3ec92d41/attachment.html>


More information about the Pd-list mailing list