--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:33 PM
On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes
wrote:
--- On Tue, 6/28/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] packaging the pddp
docs
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM
On Jun 27, 2011, at 6:45 PM, Jonathan
Wilkes
wrote:
--- On Mon, 6/27/11, Hans-Christoph
Steiner
wrote:
> From: Hans-Christoph Steiner
> Subject: [PD-dev] packaging the
pddp docs
> To: pd-dev@iem.at > Date: Monday, June 27, 2011, 9:21
PM
> > Now that the core Pd docs (i.e.
/usr/lib/pd/doc/*)
are
> split out into a > separate Debian package, I think
it could
make
sense to
> package the PDDP > docs in a kind of mirror or
replacement
package.
> Something like > pddp-doc. Jonathan, in
particular, I
was
thinking
> that since you have > wanted to work on all the patches
there,
we could
set it up
> so the > pddp-doc package mirrors the
whole
/usr/lib/pd/doc*
> directory and patch > structure, have this in SVN, git,
or
whatever
> somewhere. Then people > could choose the pddp-doc package
if they
so
choose.
The PDDP docs I did are all for
vanilla
objects
(exceptions are
expr family, and the other "vanilla"
extras). If
a new user clicks
"Help" on a vanilla object, it should
show the
revised
PDDP help
patch by default.
So instead of what you propose, please
make
something
like a
legacy-vanilla-help package.
That way,
if
someone really prefers
the old docs, they can still find
them, and we
won't
waste new users' time
by forcing them to use outdated and
unmaintained docs
(until they figure
out they're supposed to download a
separate
package
for the current
vanilla help patches, which nobody has
to do
for any
of the external
packages).
-Jonathan
I agree that the PDDP docs are much
better, that's
why I
want to get them out there more.
Part of
packaging is
representing the upstream as it is and
letting the
user
decide. So I think it makes sense to
keep
puredata-doc
as what's included in the official
tarball.
As for
Pd-extended, I think it should still use
the PDDP
docs, so
like you say, showing the PDDP docs by
default.
Ok.
So we just need a plan of attack. If you can
lead up
this project, I will help as much as I can. Do you want to
include
the whole docs tree in the doc/pddp SVN?
I'm already kind of doing that with pd-l2ork. I've revised Miller's control/audio/ds tutorials. Pd-l2ork has fixed the crasher bug when a patch closes itself, so I've got a navigation toolbar in those tutorials that is currently incompatible with pd-extended/vanilla.
Or something else? It
seems to me the easiest would be to start a separate repository
for them,
like on SourceForge, pddp is available: http://sourceforge.net/projects/pddp
Or we could reorganize doc/pddp in the pure-data
SVN.
.hc
Since Pd-extended and Pd-l2ork already use the PDDP
docs, the only thing
we're talking about here is providing PDDP docs for
people who use
vanilla, and that's a simple commit. So I don't
see why I have to head up
some new project and learn Debian packaging in order
to meander toward (or
around) that goal.
Its not a new project. I see it as a better representation of what's currently happening. You are doing great work with the PDDP docs, I think we can make the structure of that project work better for you. Having it as a distinct entity means you are less encumbered by others when making decisions about what should happen with PDDP. That distinct entity can be either a folder in the pure-data SVN, a separate SourceForge project, or whatever we think is easiest. I think one of the first two options would work well.
I'm happy to do all of the Debian packaging, that part would be easy for me.
So what is it you want me to do?
The only problem is with pddplink and helplink
dependencies, which should
just be included in vanilla as internal objects.
Is there a good reason
why they aren't?
That's something you'd have to take up with Miller, only he makes the call there. Honestly, I think we're better off keeping things as distinct libraries. Miller has limited time to spend on Pd, so the more stuff that's in Pd, the thinner his time is spread. pd-pddp is in Debian/Ubuntu/Mint etc. For someone who knows Fedora/RPM packaging, it would be really easy to package it. Then PDDP is included in Pd-extended already. So that means for the vast majority of users, pddplink and helplink are already part of the standard install.
Maybe my time would be better spent making a "gui"
plugin that just grabs
all the stuff that should be core pd but isn't and
installs it:
revised/maintained docs, [initbang], [closebang],
[pddplink], [helplink],
$@, etc.
That's done, that's called Pd-extended ;)
.hc
-Jonathan
Using ReBirth is like trying to play an 808 with a
long
stick. - David Zicarelli
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.