[Tdg] Mint updates
Rama Hoetzlein
rch at umail.ucsb.edu
Wed Mar 7 14:41:11 PST 2007
>the thing you're talking about, people making major changes that break other
>people's code, That is what branches are for.. people make these major changes
>IN the branches, so that the trunk is ALWAYS stable. Once people approve of a
>branch then it gets merged into the trunk and that becomes the trunk.
>
>
This does not resolve design issues.. It is a tool like any other. It is
certainly feasable that two people working on core develop seperate
branches that, because they never discussed design, are incompatible
with one another. Why should someone go to the effort of developing an
algorithm/implementation branch only to have it be disapproved from
merging with the trunk? It seems far better to cut off potential
disaster through an active design process. I don't think versioning
software can replace important design decisions.. This is what i've been
feeling lately. Thats all. I don't want the repository to be an excuse
not to actively discuss and solve design problems (on any issue)
To give an example with folder structure. Yes, we can obviously move
stuff around later. But a new folder structure later will not only
require that we redo all makefiles and projects, but will impact
workflow also - everyone would need to switch to the new structure. I
think these discussions are essential to our process.
However, if everyone agrees that we shouldn't worry about it now, then
that another matter. With the exception of Jorges last e-mail and Wes's
more general input ("Overall I like Alex's structure best"), its just
been me and Alex so far on the actual details.
Rama
>Everyone,
>check out the project base:
>tdg/svn/mint
>
>tell me what you think, if people think it isn't up to par we can move stuff
>around more, or revert to the thing from before.
>
>-Alex
>
>On 0, Rama Hoetzlein <rch at umail.ucsb.edu> 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
>>
>>
>_______________________________________________
>Tdg mailing list
>Tdg at mat.ucsb.edu
>http://zydeco.mat.ucsb.edu/mailman/listinfo/tdg
>
>
More information about the Tdg
mailing list