[PD-dev] sourceforge dev

[Hans-Christoph Steiner]

geiger wrote:
> 
> 
> On Sun, 18 Dec 2005, Mathieu Bouchard wrote:
> 
>>It's possible to code without CVS access too! look at how Miller works.
> 
> 
> Yes it is, but how many time does the code change ? How many times will
> the translation change ?
> 
> 
>>Translations are put into TCL source files.
>>
> 
> 
> But the translation won't change the behaviour of the program, so
> it is data. If someone puts data into source code files it would be
> good if someone (who can program) would review before the changes get
> commited. Max can just give the translations to you and you can commit
> them. I think this is a straight forward way to work.
> 
> 
>>Is TCL not enough of a Real Programming Language for you?
>>
> 
> 
> I think discussing this would take is far away from the topic.
> Anyhow, its not the point. I do not consider translation
> as programming, this doesn't have to do with the syntax of
> the dictionary entries.
> 
> 
>>How is translating not a form of development?
>>
>>Then why are Developers called Developers and not just Programmers?
>>
> 
> 
> There is no rule that only developers can be added to sourceforge. There
> is even a role called "Translator".
> 
> More than the fact that doing the translation once and getting it right
> might not be a hard thing to do, so no need for CVS, there is also a
> second reason for my opinion.
> 
> Max is probably the first developer/translator/whatever who enters in
> order to work on a forked version of Pd. This is bad. This is only my
> opinion, others surely disagree, but it is still my opinion and you won't
> easily change it with your arguments, I am terribly stubborn, you know.
> 
> See my opinion as a "political" statement, I am against forking.

Ok, I have to agree with Guenter.  We are adding a lot of people to the 
developer list and we don't really have any process to deal with it.  I 
think this can lead to all sorts of problems down the road.  I agree 
that translators don't really need CVS access, the files won't change 
much, so they can be cleared and checked in by an existing developer.

Plus, since desiredata does seem to be a fork rather than just a 
development branch, it would probably make the most sense for there to 
be a separate repository for desiredata. A branch is something that is 
created with the intention of eventually being folded back into the main 
source.  desiredata is making very large changes (AFAIK) which which are 
really too large to be a manageable branch.

This is not a vote against desiredata, but really just an issue of how 
best to manage the code.

.hc