opencog-dev team mailing list archive

["Ben Goertzel" <ben@xxxxxxxxxxxx>]

Egads!!!
I go offline for one day and this is what happens???  ;-)

After skimming this surprisingly lengthy email thread, the situation with
these different branches and the related policies is quite clear to me,
although I hadn't really been paying attention to it before, as I'm not
actively developing in OpenCog at the moment (alas ... too many business
duties...).

I'll summarize my understanding here and hope that someone will correct me
if I say something wrong.

My goal in writing this summary is not to confuse things, but rather to work
toward clarity via expressing the situation as simply as possible.

My understanding is that folks should be merging their new or modified code
into the **staging** branch.   Upon doing so they should validate that their
code works, in the sense of passing the relevant unit tests.  But, they
aren't required to validate that it works on all relevant distros and OS's.
 That is currently Gama's job.

The distinction between the staging  branch and the  main branch may
possibly be an unnecessary complication at this stage.  However, be that as
it may, I don't see how it causes any *harm*, so long as developers work in
the staging branch, as intended.  And I am confident that down the road the
split between staging and main will be valuable.  Because, as Cassio has
pointed out, the idea is that

-- the staging branch will contain code that has been validated as
functional software

-- the main branch will contain software that has been validated as
functional software, and acceptable AI

The reason to split this up into two branches is that assessing software
functionality in an automated way is **closer to possible using current
methods** than assessing acceptable AI functionality in an automated way.
 The automated assessment of software functionality, with reasonable
accuracy, is a matter of running appropriate unit tests.  The automated
assessment of acceptable AI functionality, at the moment, is an art as much
as a science.  The creation of rigorous metrics for acceptable AI
functionality is a difficult and important research topic.

Another issue that has come up is how often people merge their personal
branches into staging.  Apparently different folks have different tastes in
this regard.  I tend to agree with Linas that, all else roughly equal, it's
better for folks to merge their code frequently.  However, I have to note a
distinction between two types of development that are going on in OpenCog
now: original development, and porting of code from the proprietary
Novamente codebase.  My observation, which may be wrong, is that merging
extremely frequently tends to be more sensible when doing original
development than when doing porting.

For example, I'm thinking about two of the pieces of OpenCog code I've been
peripherally involved with: Joel's attention-allocation module, and his port
of the backward chainer from the NCE codebase.  It seems to me that in the
case of the AA module, it was pretty simple for Joel to gradually merge
parts of it into the primary OpenCog codebase as he developed them.  On the
other hand, in the case of the backward chainer, it seems more like there's
a large batch of work that needs to be done all at once before merging make
sense.  Because, large chunks of the backward chainer operate in a way
that's not really compatible with OpenCog, so that they all need to be
changed before it makes sense to merge the backward chainer.  The work that
several of the Brazilians are doing in porting parts of the Novamente
PetBrain code into OpenCog, is more similar to the backward chainer task
than the attention allocation task.

So, I think that peoples' "merging behavior" right now is heavily skewed by
the fact that most OpenCog developers right now are engaged in *porting*
code from the NCE to OpenCog, rather than doing novel OpenCog development.
 I suspect that once this initial porting phase is over, then peoples'
merging behavior will naturally become more similar to what Linas wishes,
with more frequent merging.

Finally, someone made a statement that Linas is the only one doing serious
work on OpenCog, or serious AGI-ish work on OpenCog.  This is silly, and
completely false.  Linas is doing important work, of course, and the
AGI-ish-ness of his NLP-focused work versus other folks' differently-focused
work is a subtle issue depending on one's AI theory.  However, Joel, Gama,
Erickson, Welter and others are actually doing important work in OpenCog
also.  As noted above, it happens that Erickson and Welter have been
concerned with porting PetBrain code into OpenCog ... Joel OTOH has been
doing all sorts of stuff, including creating the initial attention
allocation module, a PLN forward-chainer, and getting a long way through
porting the PLN backward-chainer.  I cannot see any good reason why anyone
would deprecate this work.  I note also that some of these same folks (e.g.
Welter) played a role in creating the basic OpenCog code on which Linas has
been building.

I think everything had already been clarified before I wrote this message.
 I hope I haven't confused thing even further.  Hopefully we can get past
this frustrating confusion and get on with development of the software!

The confusion about email lists hasn't helped, obviously.  Apparently there
was some error with the opencog-dev list wherein Linas was not receiving
email from that list.  I hope that has been resolved, but if it can't be
resolved quickly we'll obviously need to stop using that list.

The rationale for having two lists is somewhat similar to the rationale for
having a main and a staging branch: OpenCog is a software project, but also
a science project.  The idea is that opencog-dev is for code-level
discussions that would not be of interest to anyone not actively doing
software development in OpenCog; whereas the opencog@xxxxxxxxxxxxxxxx list
is for discussion of the algorithms, structures and ideas of OpenCog.   I am
not absolutely certain that this division into two lists is a good idea
**right now**, but I am quite sure that it will be a good idea down the
road, when there are more people doing software development on OpenCog.  In
this future scenario, there will be more opencog-dev messages than most
folks interested in OpenCog conceptual/algorithmic issues will want to deal
with.

So, in the creation of two lists and the main/staging dichotomy, essentially
we have set up a framework with the philosophy of "planning for success" ...

-- Ben


On Mon, Oct 27, 2008 at 10:03 PM, Gustavo Machado Campagnani Gama <
gama@xxxxxxxxxxxxx> wrote:

> Wow. This is really hard. I must be doing something really wrong here.
>
> On Mon, 2008-10-27 at 23:19 -0500, Linas Vepstas wrote:
> > > >From then on, it's up to you how to merge/rebase the current changes
> > > from main.
> >
> > Wow.  Its up to me?
>
> Yes. Well, kinda. Not in the way you seem to have understood it.
>
> Let's try this again. You have committed a few things onto the 'main'
> branch that should have gone on top of the 'staging' branch instead. All
> I'm asking is that you take these changes, merge/rebase then with the
> 'staging' branch, and push them on top of the *'staging'* branch
> whenever you think they're ready.
>
> Is that clear?
>
> > > Since you've committed a few things that have already been
> > > fixed on staging -- or another derived branch that will be merged to
> > > staging soon, such as the classserver fixes -- you might be better off
> > > cherry-picking your commits with "bzr merge -c <rev>", "bzr replay -r
> > > <rev>" or something similar.
> >
> > ?  I'm reading through your email, and what I'm getting from
> > it is that you are nominating me to be the chief maintainer
> > of everything, the whole kit-n-kaboodle.  I'm floored.
>
> What I'm trying to say is that some of the commits you've pushed to the
> 'main' branch after the 'staging' branch was published *might* conflict
> with changes that I've already pushed to the 'staging' branch. So I was
> trying to be helpful and suggested that you might want to try to merge
> your changes using those alternative commands.
>
> So, to let's state it clearly to avoid further mistakes: no one is
> asking you to become the maintainer of anything. I'm just asking you to
> migrate the latest changes you've committed to the 'main' branch on top
> of the 'staging' branch.
>
> > You want me to be the chief maintainer? I get to
> > cherry-pick whatever I feel like, and put it into main?
>
> Another note, just to make sure we're on the same page: you shouldn't be
> pushing code to main. And, right now, nor should I or anyone else. Once
> David or whoever is in the position to make this decision comes to the
> conclusion that the 'staging' branch should be pushed as 'main' (or
> 'stable', or whatever he decides to name the branch), I'll take care of
> testing the staging branch with as many archs, distros and compilers
> that I can get my hands on, running the (currently nonexistent)
> higher-level AI tests that Cassio mentioned and pushing it.
>
> > > Making sure that we have code that's compliant with all of these
> options
> > > is *my* job.
> >
> > And so then its my job to merge into main?
>
> (I'm going to repeat myself over and over just to make sure that we're
> not misunderstanding each other again)
>
> No. That's my job.
>
> > > track, here's a suggestion: keep track of the branches from the
> > > opencog-dev group (https://code.launchpad.net/~opencog-dev).
> >
> > I am having trouble subscribing to that mailing list.
> > :-/
>
> Yeah, I saw that. Fortunately the web page and access to the branches is
> public and since you have permission to commit to 'main', you probably
> have permission to commit to 'staging' as well.
>
> > > Yes Linas, yes. My point is, your suggested policy doesn't scale.
> >
> > Well,  the policy I was proposing was that
> > *everyone*  should have responsibility for
> > merging into  the trunk.
>
> Agreed. That's the way it should work. What you seen to not have
> understood, in spite of all my efforts, is that what you refer to as
> 'trunk' is now the lp:~opencog-dev/opencog/staging branch (as opposed to
> lp:~opencog-dev/opencog/main).
>
> There's also the problem that some of your latest changes ended up on
> the 'main' branch, when they should have been pushed to the 'staging'
> branch. So on the previous e-mail, I've requested you to port these
> changes to the new 'staging' branch and work on it from now on. That's
> all.
>
> > OK. Heh. Thank you for the compliment.  OK, I guess
> > I can assume responsibility, as I guess I know the code
> > the best, at this point.
> >
> > I can try to start trying to pull your code into trunk,
> > starting tommorrow.
>
> You don't need to merge code from anyone into trunk.
>
> > OK, but Dave and Cassio never once hinted that I should be
> > the one developer that will be doing all of the merges.  That
> > is new news to me.  It just never occurred to me ...
>
> And, once again, that's NOT what I've meant to say at all.
>
> > Well, I guess the game plane would then be to pull as
> > much as possible out of staging and back into the
> > trunk as soon as possible.
>
> No, that's not the plan. The plan is that, hopefully, you will start
> working on the staging branch from now on.
>
> --
> Gustavo
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~opencog-dev
> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~opencog-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Ben Goertzel, PhD
CEO, Novamente LLC and Biomind LLC
Director of Research, SIAI
ben@xxxxxxxxxxxx

"A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts,
build a wall, set a bone, comfort the dying, take orders, give orders,
cooperate, act alone, solve equations, analyze a new problem, pitch manure,
program a computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects."  -- Robert Heinlein