opencog-dev team mailing list archive

[Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>]

Hi all,

I meant to reply sooner but I had no power at home last night (for the
third time this month! argh!!)

On Thu, 2008-09-18 at 11:15 +1000, David Hart wrote:
> I like all of Cassio's recommendations. For everything but project
> work that requires major change, how about a Linux-style regular cycle
> for submitting private branches to Gama for merge into main? Say,
> every first Monday of the month or something similarly
> easy-to-remember?

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

Besides, there just doesn't seem to be enough man power to go over each
other's code before every merge. For instance, out of the 6 or 7
branches I've pushed and requested a review, only 1 got any comments so
far.

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! :-)

Announcing the branches on the list helps too, of course. But *this*
I've done every time. :-)

> Combined with a rule that no private branch should go >2 months out of
> date, this would encourage regular checkins (of course, each developer
> would be free to merge local changes to a regularly-main-merged
> private branch at whatever frequency is desired).

Not 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. For instance, the 'threading' branch. I
haven't worked on it for the past 2 months. It's unlikely we'll work on
it again in the short future. And still, it would provide us with
valuable insight once we decide to tackle the multi-threads issue again.

Forcing every branch to be rebased to main within a given deadline seems
like a rule waiting to be broken -- as people will probably have higher
priorities when the deadline comes. And a good way to waste resources,
too.

Now, just as side joke, here's the *real* reason I have so many dead
branches on my launchpad workspace: the fabulous people from Canonical
decided to *remove* the option to delete a branch in Launchpad 2.0 (!!).
About a month ago I spent at least a couple of hours trying to figure
out how to do it -- until I gave up. There's probably an obscure and
undocumented way to do it so, if anyone finds out, please let me know.

> If I grok project merging as discussed, we'll create a new permanent
> branch 'testing', and using PLN as an example the process would be: 
>       * rebase testing on main
>       * rebase pln on main
>       * merge pln into testing
>       * announce that people should *test* or *hack* or *whatever* on
>         testing
>       * merge testing into main
>       * close and remove the pln branch
>       * wash, rinse, repeat

This workflow seems fine to me. Again, the problem is convincing
*everybody* to follow it.

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

Then, we merge it back to 'main' whenever people feel that the current
tree is stable enough. With this model, people have the option of
branching from main for local experiments and the burden of keeping it
up to date shouldn't be too large as main won't change so often.

What do y'all think?

--
Gustavo