[PD-dev] repository layout

[Hans-Christoph Steiner]

On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:

> 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

Sounds good, how about downcasing while you are at it, so we have it more 
standardized.

Plus, what about adding Gem back to the main pure-data repository?

All these changes will cause major breakage to the Pd-extended build 
system, anyone want to help fix it? :D

.hc

>
>
>>
>>> - 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
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

 	zen
 	   \
 	    \
 	     \