opencog-dev team mailing list archive

[Cassio Pennachin <cassio@xxxxxxxxxxxxx>]

>
Hi,

> I don't think the current tree requires this sort of formality. I'd  
> say
> that the current recommendation -- 1. work on your own branch; 2.  
> refine
> and test it; 3. if necessary request a review; 4. merge to trunk --
> would work pretty well if *everybody* worked like that. Joel (and
> myself) seem to be following this, but there are others who are  
> not. :-(

What can we do about that?  Will such unnamed others let us know  
what's wrong with the current guidelines?  Alternatively, what can we  
do to get everyone to adopt them?

> Anyway, there seems to be some requests for more "openness" lately --
> which I believe is only fair -- and perhaps we should recommend that
> everyone publishes his/hers local branches to launchpad more  
> frequently,
> even at the early stages. I'm particularly guilty of not doing this
> (for a number of reasons: perfectionism; bzr inability to easily  
> rewrite
> the revision history; launchpad's horrible performance; etc) but I'm
> sure I can change! :-)

As maintainer of the main branch, we expect you to set the example for  
us all ;-).

> ot sure about this one either. IMHO, there are many (good) reasons why
> a branch might be left untouched, stray from main and still provide
> useful insight into future work.

This is a good point, but that's not an actively modified branch  
right now.  I think Dave was more concerned with branches that are  
under active development straying too far from main.

> > From the other replies, there seems to be a general consensus that we
> need an unstable branch. So here's a proposal: after I land the  
> 'dynamic
> modules' branch (which is a fairly large patch) and the .deb packages,
> I'll rebase it again against the latest changes from Linas and --
> preferably after others test and review it -- I'll publish it as
> 'unstable' (or whatever you'd like to call it) under the '~opencog- 
> dev'
> workspace.

Sounds good to me.

Cassio