[Tdg] Mint updates
Jorge Castellanos
jcastellanos at umail.ucsb.edu
Wed Mar 7 14:22:24 PST 2007
> 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.
> 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?
My thoughts on this point:
One of the advantages of OOP is that the behavior of a class is
decoupled from their clients (or it should be at least). Which means
that even if somebody makes major changes to how something is done,
if the interface is kept the same, then nothing should break (unless
the code has bugs or is completely broken). If such is the case, then
that's why we are using Source Control, we can just roll back...
Otherwise, it will be tedious and difficult to check every change
made to de code.
What I agree is that changes to the interface of the core have to be
discussed.
Regarding the file structure proposed by Alex (the last one he sent).
I like it. The only thing I'm not completely convinced is that the
platform dependent sources are not in the Source/ directory under
their platform name directory. But it doesn't really bother me. I'm
just unsure what would be best.
I would ad a "/Tests/" directory where we add Unit Tests or some
other way doing automated testing.
This would help reduce commiting broken code (we would run the "base"
tests before any commit).
j
On Mar 7, 2007, at 4:53 PM, Rama Hoetzlein wrote:
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
>
_______________________________________________
Tdg mailing list
Tdg at mat.ucsb.edu
http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
More information about the Tdg
mailing list