opencog-dev team mailing list archive

[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').

> 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.

> 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.

> 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. 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 have to discuss the new atom type hierarchy
with Cassio and Senna before finishing the the ClassServer changes. Etc.
etc. etc...


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.

> 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. 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, as I don't know the details of what the new code is supposed to
do. It has probably happened when I created the 'dynamic module' branch
(becaus I had to touch everyone's code) and it would happend again and
again...


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.

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

> Linas's suggestion seems sensible for regular periods with less
> drastic changes in the pipeline for staging (or perhaps staging is
> simply a transient branch which appears only when necessary to help
> merge multiple large project-based development branches)

Cherry-picking changes from staging to main, or rather, unstable to
stable makes sense when we have a release or something (but then the
'stable' branch will probably be called 'release-1.0' or something like
that, so the names don't really apply). Right now, I'm not so sure.


On Mon, 2008-10-27 at 13:30 -0500, Linas Vepstas wrote:

> Yes, but whomever is  contributing to staging has a duty
> to make sure that  they are in sync with main, which is
> what seems to not be happening.

Well, the problem is that "whomever is  contributing to staging" should
be *everyone* -- and conversely, no one should be commiting to
'main' (until 'staging' gets stable, of course).

--
Gustavo