[GEM-dev] off to new shores...

[IOhannes m zmoelnig]

chris clepper wrote:
> On Jun 18, 2004, at 6:58 AM, IOhannes m zmoelnig wrote:
> 
>> so i favour c) (with some b)): each development should be forked into 
>> a separate branch in the CVS; the core-developpers of this branch work 
>> on the code until they consider it stable and then make a call for 
>> testing via the list. after it has proven to run stable on all 
>> platforms this tree is merged back in.
>>
>> i would suggest that the releasing should be done on each merge of a 
>> development-branch to the main-trunk that adds new functionality. 
>> (this can be discussed; it is just fundamentally different from the 
>> last release)
>> the main-trunk can be used for bug-fixing...
> 
> 
> So what determines where to branch?  I can see doing one after each 
> stable release like you have done for 0.90, but the c) point mentions 
> 'each new feature is branched off' as well.  A main and dev branch 
> sounds ok to me, but I strongly favor as few branches and the simplest 
> possible CVS layout as possible.  Also, I'm not sure how well my current 
> CVS setup will handle even a single branch - could mean some headaches 
> ahead.

it is also my understanding, that branching off a stable-release PLUS 
branching each development is a bit contradictory.

as for having main vs. dev branches, it again leads to the discussion, 
who decides what goes from dev to main.

what i do not want to have, is an organization as on pure-data's CVS, 
where there are thousands of branches and i do not know what is what.

therefore branches should be short-living, that is: a branch is created, 
development is done, the branch is merged to the main trunk and vanishes.

but of course, if your CVS setup cannot handle this, all discussion is 
void (but really, i cannot believe it)


and of course: each branching and merging should be properly announced 
to this list.


> I have some pixel based stuff kicking around for 'tracking' and I want 

me too ;-)

> to get multiple video/camera sources working with Quicktime as well.  
> There is a potential project coming up that would require tracking in 3D 
> space.  Might be interesting.
> 
> I'm probably not going to put much time into GEM for a little while, but 
> I think that when I do, the focus will now be on 3D rather than 2D 
> objects.  That's probably really were both the strength and the future 
> of GEM lies.

what is still very high on my todo-list (and what i have forgotten to 
mention) is selection-buffers (Ben's mail reminded me of this) ((whoops, 
no the "other" thing is gone again;-)))


mfg.a.srd
IOhannes