opencog-dev team mailing list archive

[Cassio Pennachin <cassio@xxxxxxxxxxxxx>]

Linas,

> Over-write?  I've been doing 100% of my development in main,
> based on the assumption that was the easiest, most sensible
> thing to do. I certainly would not want to see my (several months)
> worth of work over-written!

No one is talking about overwriting your work.  Follow policy and this  
issue disappears.

> 100% of my changes go into the "main branch", since
> that is the "main" branch. Right?   Given what I am working
> on, it doesn't make sense for me to use any other branch
> than main.

Feel free to push 100% of your changes to staging if you want.  As  
long as you don't break it, it's OK.

> > > Yes, but the work on PLN doesn't/shouldn't require any
> changes to other, existing, code in main, and so, therefore,
> I see no reason why PLN could not have been done in
> the main branch.

PLN does require a number of changes in other parts of the codebase.

Joel is doing PLN development, the decision on whether that goes  
directly into staging or into its own branch is his.  The policy  
covers both cases.  For PLN integration, I strongly suspect using a  
separate branch was the right choice for Joel.  It might not have been  
the right choice for you, but that would have been a different decision.

> Well, sorry, I was unaware of any policy; or of any
> conversations about policy. Apparnetly, those occurred
> on a different mailing list, of which I wasn't aware of
> until recently.

You participated in the most recent discussions about policy and  
branching.

> > I am actually using opencog in a production environment;
> and Gama implies that the staging area is unstable.

I'm not aware of these implications.  Staging is supposed to "work".

> Therefore, this means that I cannot use the unstable branch.
> But if I can't use the unstable branch, and I can't check code
> into main, then where am I supposed to do development?

If you use it in production, it should be in a separate production  
branch.  Both staging and main are moving systems with no guarantee or  
obligation of supporting your specific production needs unless that's  
discussed and agreed on the opencog-dev list and supported by  
automated tests.  Even so, there's a number of reasons why such  
support for your needs might break eventually.  Production systems  
typically use separate, frozen branches for that reason.

> I don't see how this is a development process that can work,
> even in principle. The fact that Gama is using words like
> "over-write" as opposed to "merge" signals to me that
> the process is also broken in practice.

Although no one will say recent progress has been ideal or that these  
policies are perfectly oiled and tuned, it's been working recently for  
a number of people.

> I strongly urge that this other mailing list be abolished.  I see
> no reason for two different mailing lists for opencog -- it
> just makes everything cloudy and obscure.

You keep bringing this up.  No one else has ever complained about the  
current setup.  Last time you brought this issue up I explicitly asked  
the list if others agreed with you and no one did.  I think it's time  
you accept the two mailing list setup.

Cassio