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@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D