[Tdg] Mint updates

[Rama Hoetzlein]

I thought we had decided to keep the make files seperate from the code? 
I can see some seperate os-folders for make files, but why not just keep 
all the code together.

I agree that the folder structure needs some revision. While folder 
structure might not seem like a big deal, please don't commit the folder 
changes until there is unanimous consent from the group. I still have no 
idea what Graham and Lance (Jorge?) think about this (unless they have 
no opinions on this issue). I think getting feedback from everyone, and 
moving forward only after unanimous consent has been a valuable 
principle in our operation as a team... In the event stuff, for example, 
I tried to make it my own personal practice to actively confirm 
agreement with everyone in the team before posting anything - thats why 
it took so long, but the result is that everyones' efforts are present 
in the design. The current event code looks nothing like what i, or 
someone else, might personally come up with (it has elements of all our 
efforts) - but it is much stronger i think because we worked together 
until we had really resolved the issues...

Does anyone else have any opinions of folder structure? People like 
Alex's structure more. Ok, no problem.. My bigger fear is that we're not 
considering some of the details of these decisions more carefully. 
Everyone fought like hell over the event code. Is there no discussion on 
what impact folder structure will have down the line? I hope its clear 
my concern lately has nothing to do with folder structure, but with 
group dynamic / decision making.

Now that the code is committed, I hope that having a repository does not 
destroy our group process of unanimous consent - especially when it 
comes to core decisions. Certainly, when we get into systems people can 
work more individually. But obviously we cannot have team members 
committing major changes to memory_pools for example, in such a way that 
it is incompatible with another person's development in a specific 
system. Someone says: "Oh yeah. I just implemented some majorly awesome 
improvements to the memory_pool. It's soo much better than the previous 
stuff.".. And we all say, yay! But the result is, due to their design 
(not just a bug), it causes major crashes with another (sub)system in 
development. In this example, the guy working on memory_pools (or folder 
structure) should get unanymous consent from the group before 
committing, right? But on what? Definitely interface (API), probably not 
specific details of implementation (if its buggy, he/she should fix it), 
but how about overall implementation design for the new core thingy (ie. 
structures/algorithms)?  Now that we have a repository, where will we 
draw the line between what people can commit without consent and what 
people are required to get unanymous approval for? While not immediately 
practical to mint itself, I hope that we can have discussions on these 
kinds of things as well.

Alex has posted at least 3 different possible folder structures over the 
past two weeks (1. branches / trunk, 2. single folders for all code, 3. 
seperate the folders by OS). Does anyone else have an opinions on this?

Rama

PS. Since i love mint so much (the herb anyway), I will be at the 
meeting tomorrow (thesis be damned) : )


Alex Norman wrote:

>there is no need for branches/trunk at this point in the game, later on we can
>always move to that structure [it is simply an "svn mv" call]
>
>the linux/osx/windows folders are for os specific code and building stuff (ie
>make files, visstudio projects, etc)
>
>so we'd have something lke this
>/tdg/svn/mint/
>	core/
>		bin/
>		include/
>		linux/
>			Makefile
>			x-lib b.s.
>		osx/
>			xcode thing.
>		windows/
>			vis studio solution
>			windoze specific typedefs, etc.
>		source/
>	audio/
>		..same structure as above
>
>-Alex
>
>On  0, Rama Hoetzlein <rch at umail.ucsb.edu> wrote:
>  
>
>>Ok.. I can't resist. If no one else has any opinions on file structure 
>>(hard to believe), i do : )
>>Do we really need linux / osc / windows folders?
>>
>>Won't it be obvious from the makefiles, projects, etc. which files get 
>>included on which platforms? Besides, I don't think there will really be 
>>that many OS-specific files. Why not just put everything in source and 
>>include?
>>
>>Alex, can you give us a run-down of the whole file structure you're 
>>considering? Are bin, output, docs, make folders still at a higher level 
>>than whats shown below? I mean, is it like this?
>> /tdg/svn/mint/bin
>> /tdg/svn/mint/core/... (stuff below)
>> /tdg/svn/mint/output/
>>
>>Or did you have something else in mind? Also, i don't see branch / trunk 
>>(this is necessary for svn isn't it, maybe not). (PS. If it was taken 
>>out, cool : )
>>Was there a discussion about this? Is that between /mint and /core?
>>
>>Rama
>>
>>
>>Alex Norman wrote:
>>
>>    
>>
>>>Yo, sorry I'm really busy right now, I wanted to get some sort of response 
>>>about
>>>the project file organization,, I'd like it to be like this:
>>>
>>>/tdg/svn/mint/
>>>	core/
>>>		source/
>>>			all cross-platform shit...
>>>		include/
>>>			all cross-platform shit...
>>>		linux/
>>>			linux specific h/cpp and build [organized however I 
>>>			see fit]
>>>		osx/
>>>			osx specifc h/cpp and build [organized however you 
>>>			see if]
>>>		windows/
>>>			windows specifc h/cpp and build [organized however 
>>>			rama wants it]
>>>
>>>	audio/
>>>		source/
>>>		include/
>>>		...
>>>
>>>	doc/
>>>
>>>I figure it is simple, it separates the things that should be separated, 
>>>and we
>>>can always move shit around later
>>>-Alex
>>>
>>>On  0, Wesley Smith <wesley.hoke at gmail.com> wrote:
>>>
>>>
>>>      
>>>
>>>>in the igert trailer.
>>>>
>>>>wes
>>>>_______________________________________________
>>>>Tdg mailing list
>>>>Tdg at mat.ucsb.edu
>>>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
>>>>  
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>Tdg mailing list
>>>Tdg at mat.ucsb.edu
>>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Tdg mailing list
>>Tdg at mat.ucsb.edu
>>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
>>    
>>
>_______________________________________________
>Tdg mailing list
>Tdg at mat.ucsb.edu
>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
>  
>