Hey all
I compiled some externals for several platforms to be used with Deken. Now, I'm thinking about stream-lining the process and I stumble across some culprits and I still have lots of questions.
Here the list of externals / libraries I'm interested in maintaining builds:
iemnet osc (mrpeach) slipdec / slipenc (mrpeach) ggee zexy readdir (moocow)
The platforms I intend to support: Linux-i386 Linux-amd64 Linux-armv6 Windows-i386
(I'd love to support OS X, but have little knowledge and no access to an OS X machine).
Currently, the different libraries use different build tools. Many use the template Makefile, some others like readdir come with their own autotools setup (which uses ancient defaults, btw). Slipdec/slipenc don't have any Makefile at all (probably they're meant to be part of mrpeach library) but compile fine with the template Makefile.
Also, there is Katja's new standard Makefile available, which is obviously actively maintained and thus I'd prefer to use that instead of the template Makefile in svn.
Now, before I dig too deep into stuff, I'd like to hear some opinions from pd-dev. First, how feel people about me maintaining builds of their source code? It seems for most externals no one maintains builds, that is why I'd like to do it. Zexy already is available in Deken, but shows up with weird, non-standard names. I don't need to maintain zexy separately, if you - IOhannes - have intentions to do that yourself.
Also, there is the old rule, that devs only commit to their own folder in svn. Now, some parts haven't been touched for years and it seems cumbersome for everyone involved to make requests to the original author to apply certain changes. Should I commit my changes (build system stuff) directly to svn (i.e. by ignoring that rule)? Or would it be better, we move the maintained stuff out of svn and host them as git repository under the pure-data umbrella on github.com? Or am I better of with just doing my stuff privately (as I did for now)?
I don't want anyone to think I plan to take over "their stuff". I happily continue if no one minds, but if the authors of the listed libraries prefer to maintain builds themselves, please just say so.
Roman
On 2015-07-06 13:20, Roman Haefeli wrote:
is why I'd like to do it. Zexy already is available in Deken, but shows up with weird, non-standard names. I don't need to maintain zexy separately, if you - IOhannes - have intentions to do that yourself.
note that most things i currently uploaded is for *testing the plugin development*, and not actually meant as the official deken packages.
this is a bit unfortunate, but i guess it cannot be helped for now.
as for the "non-standard names": no. i consider it a feature that you can give a "title" to each uploaded file on puredata.info, which need not have anything to do with the actual filename. if you upload a file via deken (or simply don't care to provide a proper title), then the system choses the filename as a (reasonable) default. now the deken-plugin currently displays this title, which sometimes appears to be out of context (e.g. "OSX universal builds" makes totally sense on the puredata.info webpage where this is an item within the zexy/2.7.12 release; it makes less sense within the deken-plugin where this context is missing). i consider this a bug in the deken-plugin not on the upload platform.
fgmasdr IOhannes
On 2015-07-06 13:20, Roman Haefeli wrote:
lso, there is the old rule, that devs only commit to their own folder in svn. Now, some parts haven't been touched for years and it seems cumbersome for everyone involved to make requests to the original author to apply certain changes. Should I commit my changes (build system stuff) directly to svn (i.e. by ignoring that rule)?
i don't think you should *ignore* the rule. however, if you talk to the "owner" of a directory, they might be ok with you committing there directly. as for the un-owned libraries (e.g. the original dev moved to other shores), the more popular ones have a "maintainer" that takes care of them. just check the latest commits to find out who that would be. as i see it, you are trying to become "maintainer" of these libraries.
Or would it be better, we move the maintained stuff out of svn and host them as git repository under the pure-data umbrella on github.com? Or am I better of with just doing my stuff privately (as I did for now)?
my personal perference is modelled after Debian, where the development ("upstream") and the maintenance ("Debian") are two different things and are to be kept separate. i think this is the only proper way that allows for multiple build workflows and setups. using a unified build-system (template/Makefile, katja's pd-lib-builder) are greate initiatives for *upstream*. they *also* make live significantly simpler for maintainers (as they can apply the same logic to multiple packages). at the same time, maintainers should be prepared to tweak out-of-the-ordinary build systems.
i have started something like this with my "pd-iem" project [1], a kitchen-sink builder for a few selected libraries. it's probably a tad complicated to setup and running, as it is targeted at automated builds.
btw, my secret plan was to convert the pd-iem libraries to deken packages sooner rather than later (these include w32 and osx binaries; all libraries included in pd-iem are also packaged in Debian, which deken can use by now as well).
fgmasd IOhannes
On 06/07/15 19:20, Roman Haefeli wrote:
I compiled some externals for several platforms to be used with Deken.
\o/
Also, there is the old rule, that devs only commit to their own folder in svn. Now, some parts haven't been touched for years and it seems cumbersome for everyone involved to make requests to the original author to apply certain changes. Should I commit my changes (build system stuff) directly to svn (i.e. by ignoring that rule)? Or would it be better, we move the maintained stuff out of svn and host them as git repository under the pure-data umbrella on github.com? Or am I better of with just doing my stuff privately (as I did for now)?
A centralized SVN repository with all externals in it seems like it has been a point of friction in the Pd development ecosystem.
You could set up your stuff in Github repositories, and if somebody wants to continue to use SVN and also wants your fixes then they can figure out how to merge them back. I would make contact with people who are doing packaging of the externals for distributions and tell them that you have versions of those externals with newer modifications and they can decide whether to continue to use the SVN version or your newer versions with changes.
Hm, maybe this is too aggressive a strategy, I don't know.
In any case, I don't think there is anything inherently wrong with forking code and putting it in a Github repository and making improvements. That's basically the whole point of FLOSS. Then if people want to use your new versions, great.
I don't want anyone to think I plan to take over "their stuff". I happily continue if no one minds, but if the authors of the listed libraries prefer to maintain builds themselves, please just say so.
The sound of crickets and tumbleweeds blowing by is the universe's way of telling you to do whatever the heck you want. :D
Cheers,
Chris.
-
Chris McCormick -
IOhannes m zmoelnig -
Roman Haefeli