On Sep 26, 2011, at 1:59 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Marvin Humphrey marvin@rectangular.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Richie Cyngler glitchpop@gmail.com; "pd-list@iem.at" <pd-list@iem.at
Sent: Monday, September 26, 2011 12:54 AM Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"
On Sun, Sep 25, 2011 at 05:33:22PM -0700, Jonathan Wilkes wrote:
If you are planning on making substantial contributions to Pd
Vanilla,I wouldn't say I'm "planning" on it -- more that I'd like to keep that option open.
you should consider making a few "test" contributions to gauge
the amount of
time and energy it will take you to get patches accepted;
something like a patch for getting this <control-enter> key binding would be a goodstart.
Indeed, I've already started that process, by negotiating the shape
of the patch to come and building consensus. :) There's been some
question as to what key combo should be used. It seems that [modifier]-Enter is
already in use and people are happy with it, so I'll go that direction despite
my mild personal preference for <ESC>.A patch which has consensus support from the community probably has
a better chance at being applied, even under BDFL governance. :) But
consensus can be costly to achieve depending on the project's culture...Also, realize that any substantial changes you make may sit in the
patch tracker for some time -- it's not easy getting them accepted, nor communicating with Miller if they don't.Well, controlling entities for open source projects have to be
responsive to their communities. If they are not, they get forked, or people
move on to other things.It's been forked-- four times (AFAIK). Nova, DesireData, Pd- extended, and Pd-l2ork. Two of those forks-- Nova and DesireData-- had explicitly stated goals which basically boiled down to being more responsive to the Pd community (in addition to many other things).
There was also pd-devel, which was probably the first big big fork. I
think that you can think of Pd has a kind of association of forks. As
the maintainer of Pd-extended, I try to contribute as much as possible
upstream to Miller, but I also include a number of things that I think
will probably never make it into Vanilla. pd-l2ork seems to be born
out of Ico's frustration with the work it takes to submit clean
patches. I try to follow the development since the l2ork crew did
very nice work like getting the Magic Glass working again. But its
very difficult to do since pd-2lork does not seem to use any source
code management, just tarballs.
Forks are a good thing as long as we lay the basic ground rules to
keep things compatible and reasonably in sync. It means that we can
have more development and testing of ideas. git makes this much
easier once you learn it, but git takes quite a bit of learning to
really use it well.
I believe the author of Nova moved on to developing parallelism for Supercollider, which will probably become a core part of Supercollider well before any revision of his 7-year old tooltip patch ever gets
included in Pd Vanilla. So as a perfect example of your theory, yes-- Pd gets forked, and/or people move on to other things!
To be fair, after that tooltips patch was submitted, Miller expressed
his problem with how the patch was implemented. No one ever bothered
to follow up on that, so yes, that patch made no progress.
Pd-extended and Pd-l2ork are extant. There there has been some effort to lessen the number of core differences between Vanilla and Pd-extended.
On my part, there has been a lot of effort to do keep Pd-extended in
sync, but its not just on this list or in public forums. Before I
started the pd-gui-rewrite, there was a lot of discussion about what
Miller would accept, and I worked within those guidelines. These
days, Miller is mostly using Pd more than working on Pd, so Vanilla
reflects that. It seems it is working for what he wants to do, and
that's what free software is all about, scratching your itches. :)
If you want to see one way I keep Pd-extended in sync, clone the git
repo and checkout the 'patch_series' branch. Pd-extended is
maintained as a series of patches to Pd vanilla from the pure-data.git
repo. This way I can develop, test, and release code and then easily
cook them into well polished patches to submit to Miller.
.hc
But it's also generally true that large, boil-the-ocean patches are
costly to review, especially for stable projects with large user bases, and so contributors are well-advised to bear that in mind and prepare small, easily-digested morsels when possible.Additionally, if they are big, desirable improvements to the Pd
community they may find their way into Pd-extended anyway.So long as contributions to Vanilla are integrated into Pd-extended
in a way that adheres to the provisions of Vanilla's BSD license, then
there's no problem. :)The three clauses of the BSD license used by Pd Vanilla are
compatible with both the GPL v2 & v3-Jonathan
Cheers,
Marvin Humphrey
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams