[PD-dev] distributing libraries (was Re: svn:externals "sucks", or tracking changes in Gem)

[IOhannes m zmoelnig]

hi

it's early in the morning and while writing the below lines, i notice 
that i am grumpy as ever.
you can probably just skip the rest of the email :-)

Hans-Christoph Steiner wrote:
> 
> On Sep 10, 2008, at 3:26 AM, IOhannes m zmoelnig wrote:
> 
>> Hans-Christoph Steiner wrote:
>>> developers together.  But it is not working so well now, perhaps 
>>> because it isn't clearly defined, or because we have different needs 
>>> now.
>>
>> do you think so? and why?
> 
> One example: There are lots of people who want to use a separate 
> repository.  There isn't a clean way to include that code.  Plus we are 
> having to discuss how to use the SVN a lot, so there are conflicting 
> ideas of how we should use it.

i think there are 2 main reasons why people prefer their own repositories:
- they want to be independent
- they believe that the puredata repository is not meant for them

#1 is a social issue; i don't think it can nor should be solved!
people will always want to have some freedom of choice, even if they 
finally chose mainstream.
for me, it's the main reason to not have Gem in the puredata repo.

#2 is (i guess) mostly because of our (yours and mine) discussion about 
what the svn is actually for; if people are prohibited to import their 
code into the repository because it is under development, it is no 
wonder that they won't want to develop in this repository.

my (well know and simplistic) approaches favour development rather than 
stability. no need to discuss them again, i think :-)


> 
>>> - For Pd-extended, there needs to be a repository to do code freezes 
>>> and bug fixes, branches work pretty well for that.
>>
>> which is what we have now.
>> the important thing is (imho), to not distinguish between "upstream" 
>> versions and "packaging" versions as far as possible.
>> since the Pd-community is so small, i don't think this is a real 
>> problem to maintain (unlike e.g. with debian)
> 
> That's why I think making a clean and easy to use library format is the 
> #1 priority.  Then people maintain their own releases.

hmm; grumpy mode on:

"That's why I think making a clean and easy to use library format is the 
  #1 priority." --> i think we again hit the "social barrier" i was 
talking about in the last paragraph; (at least if i correctly read the 
"easy to use library format" as the one and only libdir format proposed 
so many years ago)

"Then people maintain their own releases" --> sorry i cannot resist: 
that's a fine piece of freedom, what else to we want

:grumpy mode off


> 
>>> - for making a central place to find code, I think we'd be better off 
>>> with a 'libraries' page like http://processing.org has.
>>
>> yes: yet another page to maintain!
> 
> If that page was a wiki page, it would open up the maintenance to more 
> people.  

ouch, sarcasm mode on: like all the other well-accepted 
community-maintained wiki pages on puredata.info? (ok, that's a bad wiki 
engine, how about...:) or more like pdpedia? (i just wanted to check it, 
but unfortunately it is currently down)

> Plus they wouldn't have to learn/use SVN if they didn't want 
> to. 

so what?
do you imply that svn is too hard to learn?
esp, do you think that it is harder to learn than any markup language?

> With the current system, you have to be a developer in the pure-data 
> project and you have to use SVN.  So it would be a matter of shifting 
> maintenance.  Plus this information doesn't change a lot.  Here's the 
> page in question:
> 
> http://processing.org/reference/libraries/index.html

yes i was aware of that page (though it took me some time to find it).

it somehow reminds me of http://puredata.info/community/projects/software
which is a bit sparse because nobody but me commits to it; even though 
it is open to all members of the portal to put stuff there...
what does this tell us?


fdgmasrd
IOhannes

PS: had to changet he subject, cannot read the "sucks" anymore...