opencog-dev team mailing list archive

[Cassio Pennachin <cassio@xxxxxxxxxxxxx>]

Hi,

One of the major benefits of DVCS is easy branching, and there should  
be a good reason for a policy that strongly discourages branches.   
What is that reason?

I can quickly think of numerous reasons in favor of branches.  For  
instance, Joel's work involves lots of changes to lots of different  
parts of the code.  The natural way to do this is by branching and  
merging once all changes are completed and tested.  This is true for  
any such change, even if the resulting branch would be short lived.   
Discouraging branches for this kind of thing encourages people not to  
commit their work.

Also, based on Novamente's development history, one can expect that  
many OpenCog macro-tasks will require extensive fiddling with  
different aspects of the codebase, often in unexpected places.  While  
it's certainly possible to perform all these experiments within the  
main trunk without breaking anything, that's not the most likely  
outcome.  The most likely outcome is that breakage from experimental  
work will happen often if the default policy is to work directly from  
main.  This is especially true for AI researchers / scientists who  
aren't experienced software engineers, yet can be invaluable for  
OpenCog.  In this regard, OpenCog development is very different from  
regular software development, and I think our policies have to  
consider this.

Finally, the "everyone works directly from main" means we have  
essentially no gatekeeper to decide what gets merged into main, and I  
don't think this is a good idea, at least now and in the short term  
future.

I believe we need a set of practices and guidelines for development  
and merging in order to minimize breakage, overhead for maintainers,  
and overall frustration.  But I'm not sure these guidelines should be  
single-branch-based.

>   - make a temporary 'stable' snapshot branch of main
>   - merge major work branches into main (at least thee of these:  
> Gama's
>   work, Joel's work, Erickson's work)
>   - together, hammer on main until everyone is happy with it again

On a more detailed note, shouldn't it be the other way around?  Keep  
main "stable" and have an unstable branch where stuff is merged onto,  
and then ported over to main?  I.e., don't break the main build.

>   - exceptions (i.e. new branches) should be discussed here or  
> #opencog
>   - EVERY new branch should be preceded by a wiki page that  
> describes its
>   location, purpose and plan for merging back into main

I believe these are good ideas with a bit of flexibility.  First, I  
think branching should be the default.  But I think every branch  
that's expected to be merged back into main should be announced here  
or #opencog and documented in the wiki.

> We should meet briefly once per week on IRC just for status, notice of
> upcoming merges, gripes, etc. I suggest the 15 minutes before Ben's  
> OCP
> tutorial each Wednesday tutorial at #opencog-dev (can be created ad- 
> hoc).

And this, definitely, is a great idea.

Cassio