opencog-dev team mailing list archive

["Linas Vepstas" <linasvepstas@xxxxxxxxx>]

2008/10/27 Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>:
> Hi,
>
> I'm replying multiple messages inline to save some time.
>
> On Mon, 2008-10-27 at 12:37 -0500, Linas Vepstas wrote:
>
>> As best as I can understand the policy, as outlined
>> in the above messages, is that "someday" someone
>> will merge all of these different branches back into main.
>
> No. The policy is: everyone should be branching off of 'staging', and
> rebasing from it and pushing into it when the feature is finished. Then
> when 'staging' is deemed 'stable', I'll merge (or rather overwrite) it
> into 'main' (or 'stable').

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!

Surely the words "merge" and "over-write" have very different
meanings, I dislike the way they just got used as if they're interchangable.

>> However, on talking to Joel, I get the impression that
>> some of these changes are quite large, and thus,
>> I suspect that the merge will destabilize the main branch
>> (which I would dearly like to perceive as stable, since
>> I actually use it).
>
> Right. That's why Joel's changes, mine and hopefully your's too will
> land in 'staging' first.

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.

>> Thus, once again, I would like to reiterate: the
>> policy *should be* that merges should be made
>> as small as possible, and done as often as possible,
>> as this will make it less likely that new bugs will be
>> introduced, and will be less destabilizing.
>
> Well, I disagree with this. When it makes sense, yeah, commits should be
> small. But larger changesets should be self-contained, and should be
> properly tested and reviewed before they go in. Commiting half-finished
> work only makes bisecting harder and polutes the version history.

OK. But it seems that it also makes merging harder.

>> However, from what I can tell, no one, other than me,
>> has committed to the main branch in *many months* !!!
>> which tells me that either
>
> Because the work Joel and I have been doing for the past months isn't
> stable. PLN, afaik has been rather painful and is not complete.

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.

> The
> dynamic modules hasn't been ported to Win32 nor widely tested yet. The
> petaverse port changes were finished on friday, but unfortunately I've
> uncovered a bug recently.

I don't know what these are, so I can't comment.

> On Mon, 2008-10-27 at 12:52 -0500, Linas Vepstas wrote:
>
>> As Joel points out, the problem here seems to be that the staging
>> branch, and the main branch has diverged. That is, some of the
>> code that he needs is in staging, and some is in main -- and he's
>> stuck, because there is no one branch that has everything that he
>> needs.
>
> That's because you commited to 'main' after the policy to branch all new
> work from 'staging' was in place.

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.

But you imply that its bad to merge into the main branch?
You're comments, above and below, imply that "main" is not
"main" any more, and that there is a new "main", which
is called "staging".

>> Presumably the problem arose because no one is  rebasing
>> staging on the current main branch.
>>
>> Thus, one of the policies should probably be "rebase staging on
>> main every day", or at least weekly.  Would that work?
>
> That's nuts! The burden of merging/rebasing new code shouldn't be on the
> maintainer of the staging branch, but rather on the developer of the new
> code.

Yes, exactly!  And that is *exactly* why the staging branch
should be rebased on main *daily*!

> First, because I couldn't possibly ever keep up with the amount of
> work if we ever have more than a couple of people commiting to 'main';
> and second, because invariably I'll make mistakes when merging the new
> code,

And this is exactly why there is a staging branch!

> On Mon, 2008-10-27 at 11:15 -0700, David Hart wrote:
>
>> Effectively today main should be under a checkin freeze; small patches
>> should go directly into staging, making a main -> staging regular
>> update unecessary.

I am actually using opencog in a production environment;
and Gama implies that the staging area is unstable.
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?

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.

> Hmm... I thought we had this in place when this message was posted. :-(
> https://lists.launchpad.net/opencog-dev/msg00389.html

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. For example,
it allows some developers to make "policy" while other
developers are completely unaware of that "policy".

--linas