On Mon, 17 Jun 2002, [ISO-8859-1] Juha Vehvil�inen wrote:
Good news!
My id in sourceforge.net is "jusu".
Is there a tree structure to think of.. or will it .. happen by itself?
Yep, there is something we have to think of, reading the docs of sourceforge it seems to be a bit complicated to change it later, ....
My proposal as a starting point for discussion:
cvsroot -> pd (The pd source, playground for tcl/tk hacks, fonts, and probably other improvement and bugfixes. If this works out, we might do some serious stuff here, having different branches and ideally Miller doing his updating this too. So we could have a miller branch, and a hackers
cvsroot -> abstractions place for patches, effects etc, ... cvsroot -> gem cvsroot -> externals -> <externalpackage1> <externalpackage2> : <externalpackagen> release
The external packages should be put into the externals subdirectory as they are (I think most of them have a top directory, which will later serve as a module name too).
The idea of the release project is to put symlinks to the different externals there and provide na additional build systems. First the simple things, later we think about externals that depend on libraries, or external libraries that use common code.
This way, the externals that are in release are the ones that the developers think that should be in releasable state, still everyone can toy around in his specific externalpackages, have non working and experimental stuff in there.
The stuff in release will be used by the autobuilders too.
I hope this will get us a fast start, because for the developers in the first place nothing changes. They just have to import their package using "cvs import externals/<externalpackage> vendor-tag release-tag", or the equivalent in wincvs.
I would prefer to build standalone externals wherever possible, instead of libraries. Thats why gem is not really part of the externals subdirectory.
Comments welcome, there is a lot left to say, define, write down, etc.
Guenter
Hi there,
I got positive response from the sourceforge team that they will host to project.
Here are the next steps to be taken:
The cvs server is cvs.pure-data.sourceforge.net
Hi,
I prefer standalones also, but don't see the point in separating them from libraries. How about libs such as zexy, ext13, joystick ... ? I think these should all go under externals along with gem..
Jusu
I would prefer to build standalone externals wherever possible, instead of libraries. Thats why gem is not really part of the externals subdirectory.
On Mon, 17 Jun 2002, [ISO-8859-1] Juha Vehvil�inen wrote:
Hi,
I prefer standalones also, but don't see the point in separating them from libraries. How about libs such as zexy, ext13, joystick ... ? I think these should all go under externals along with gem..
AFAIK they are compilable as standalone too. But you are probably right putting Gem into the externals.
the point about not doing so was that there will be only two packages (downloadable tar (zip) files) at the end, one pd-externals, the other Gem.
Guenter