[PD-dev] repository layout

IOhannes m zmoelnig zmoelnig at iem.at
Tue Sep 11 22:09:18 CEST 2007


Mathieu Bouchard wrote:
> On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
> 
>> - moved abstractions&extensions&xgui&Framestein into externals
> 
> good thing, as long as "abstractions" does not become a subfolder of
> "externals"... but I would rather have it under a common name that isn't
> "abstractions" nor "externals".
> 
> I suppose that "xgui" and "Framestein" retain their folder, whereas
> "abstractions", "externals", "extensions" contents are merged together.

this is basically correct:
./Framestein will become externals/Framestein
./abstractions/purepd/ will become ./externals/purepd
./abstractions/footils/list-abs will become ./externals/footils/list-abs


> 
>> - desiredata&pd-devel live beside "pd" (not in a separate branch)
> 
> If Thomas hasn't changed his mind, pd-devel is going to be obsolete
> soon. The latest changes still have to be picked up from there and moved
> somewhere else, such as sf.net patchtracker and the desiredata branch,
> but for all practical purposes, there will be no such branch. Let me
> also say that pd-devel very much deserves to be a branch (rather than a
> plain folder) because it has rather high mergeability with Miller's branch.


yes this fits perfectly into my layout: once pd-devel is abandoned by
all active developers (this is: thomas), the folder will be _moved_ from
./trunk/pd-devel to ./tags/pd-devel/pd-devel-<versionnumber (or the like)
all the revision history will stay intact while at the same time, nobody
has to care about a "dead" pd-devel laying around in the trunk.
if, at some point, somebody desides to re-start pd-devel (not that i
think somebody would; but just as a theoretical example), the latest
folder (from which one would like to start) would be _copied_ to the trunk.

> 
> In contrast, for the new DesireData (since dec.2006), I no longer
> attempt mergeability of any part of it. There's no future goal of
> keeping any part of the code in sync with pd for any reason whatsoever.
> All the sync necessary is to be done using automated tests (no matter
> how much work that is, it's worth it)


that is exactly why i do think that folders are so much better than tags.
currently, "desiredata" is a branch of "pd", implying a common code-base.
a folder is just a folder, it doesn't imply very much.
i believe that putting "desiredata" besides "pd" gives both of them a
kind of "equality".

> 
>> - "supercollider" has moved into scripts (i am not sure about this, but
>> it seems to be the best place, since "bash_completion" is already in
>> there; "supercollider" is no external, it is rather a set of sc3-scripts
>> to ease the use of pd&sc together)
> 
> "scripts" is a vague name I'd get rid of. Also, "gripd" contains a high
> ratio of non-"abstraction", non-"external" files. I don't know whether
> this ought to be taken into account when categorising projects...

most stuff in "scripts" currently are "scripts".
"supercollider" would not necessarily fit in there ("bash_completion" is
not a script either, that's what made me think of that)
probably we should just create a new category "misc" _besides_
"scripts", and put both "supercollider" and "bash_completion" (and
probably "gripd" in there)


> 
>> both branches/tags should only be used for:
>>  - releases (+maintenance)
>>  - legacy (discontinued) projects
>> for quick experimental branches (e.g. if you want to implement a
>> feature but do not want to spill the trunk), i would suggest a 4th
>> meta-directory "experimental", like:
>>  /experimental/pd-0.40-kiosk/
> 
> I don't know why you want this. You say what people should do according
> to yourself, but you don't explain what's your motivation for it.

my motivation behind all this is to keep it simple on the long run.
however, i admit that this motivation might lead to over-complicated
plans (which is bad).
otoh, i think if there are some "guidelines" on where to put stuff, i
guess people might happily accept them (even if these guidelines might
seem to be sub-optimal on the first glance).
finally, a suggestion implies discussion: i do not say what people
should do according to myself, but i rather ask them whether they would
like to do it "my way"; this is a difference

btw, i find it herzerfrischend that you so readily discovered that there
are only my projects in my proposal of an experimental folder.


fmga.r
IOhannes







> 
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev





More information about the Pd-dev mailing list