On Sep 26, 2011, at 1:59 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Marvin Humphrey <[email protected]>
To: Jonathan Wilkes <[email protected]>
Cc: Richie Cyngler <[email protected]>; "[email protected]" <[email protected]
>
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 good
start.
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
_______________________________________________
[email protected] 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
