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
[email protected]
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
zen
\
\
\[D[D[D[D_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
