opencog-dev team mailing list archive

[Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>]

Hi again,

I'll skip what has been already answered by others to try to keep this a
bit shorter.

On Mon, 2008-10-27 at 17:20 -0500, Linas Vepstas wrote:

> I don't know what has been said "over and over", and I
> don't know what it means to say "should be branching
> off of staging". What should be branching what off of
> which staging, where?

(sorry if my english came out a bit broken here... I'm starting to
realize this happens a lot more than I like to believe :-( )

By branching off of staging, I mean that new code should start with:

prompt$ bzr branch lp:~opencog-dev/opencog/staging <local-branch-name>

>From then on, it's up to you how to merge/rebase the current changes
from main. 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 work with *two* bzr repositories: the "main branch", which
> is hosted at launchpad, and my personal staging branch,
> which is located on my personal machine.  I rebase my
> personal branch from main every day, and I push to main
> every day. I do not push to main *until* my staging branch
> has been tested, and works well.

Unfortunately, what one considers as "works well" varies from people to
people. For instance, someone could say that good code has to be tested
against multiple configure options, multiple distros, multiple archs,
multiple compilers, etc etc etc, *before* committing. But I think we all
agree that this is far from reasonable. Nobody would get any work done.
But on the other hand, that's the kind of "testing" most people would
expect in code we tag as "stable".

Making sure that we have code that's compliant with all of these options
is *my* job. That's also -- imho -- why a staging branch is useful: so
that people can contribute code without bothering (too much) with minor
variations between environments and at the same time providing a stable
(as in *really* tested) branch to the "community".

I'm not saying we are there. The main branch is far from *really*
tested. But I think that the policy created by Dave and outlined by
Cassio on the other message is trying to get us closer to that.

> Last time we had this conversation, it was noted that there
> were 20-25 different staging branches registered on opencog.
> Many of these proved to be stale. It was recommended that
> the stale branches should be deleted.  It looks like they were,
> and that now we are down to four branches, called
> 
> "trunk", "framework", "freecore" and "opencogprime"
> 
> This is what I currently see listed at
> https://launchpad.net/opencog

Not really. The link you provided lists what you've called branches as
'series and milestones', as stated in the section header.

The link you're probably after is https://code.launchpad.net/opencog.

The ~25 branches are still there. But you've actually made a good
suggestion at that time; I have cleaned my stale branches at the time
and will probably do it again soon. I can't do anything about branches
from other people, though.

If you find the list of branches from the opencog *project* so hard to
track, here's a suggestion: keep track of the branches from the
opencog-dev group (https://code.launchpad.net/~opencog-dev). Those are
the branches where work ready for public consumption should go.
Eventually, someone might make a request to test/merge code from their
personal workspaces, but it's unlikely that you'll be affected by that.
And the 'private' nature of the branch 'label' will be clear from the
branch's label (for instance, lp:~gama/opencog/rest is obviously stored
under my personal workspace). 

A bit off-topic, but since we're discussing the ~opencog-dev branches:
Dave, there's a stale branch that I'd previously pushed to the
~opencog-dev workspace (libatomspace) that I'm unable to delete now as
there's someone else subscribed to it. Could you do it for me, please?

> I do not see any other registered branches. I commit to
> trunk. I assume that you and Joel are committing to one of
> these other branches.

No, we're working from lp:~opencog-dev/opencog/staging. I have added a
link to the message where this was announced on the first or second
e-mail that I've sent to this thread. If you had bothered to click on
the link and read the message you'd probably be aware of that now.

> The problem that Joel was having is that trunk (which is where
> I commit) has gotten out of sync with one or more of these
> other branches. The goal of this email thread is to ...
> resolve this?

That's one way to look at it. Another way is to look at it is that you
have committed code to a branch when you were not supposed to. And even
after we have repeatedly asked you to rebase your latest work off of the
proper branch, you've preferred to complain about the current policy or
claim not to know about the existence of such a thing. :-(

> Heh. I still misundertand. Are you being sarcastic?

Yes. I was a bit pissed. Sorry about that. And I'll add <sarcasm> tags
next time. :-)

> > Yes, sure. I'll spend 90% of my time resolving conflicts of code I don't
> > fully understand. That should be very productive.
> 
> I assume you are being sarcastic, right?

Yes Linas, yes. My point is, your suggested policy doesn't scale. Maybe
I'm being naive, but my understanding is that, hopefully, if we do
things right, in a few months or years there'll be more than just you,
Joel and me working on opencog. And then, it'll be impractical for me to
keep rebasing everybody's latest changes from "main" to "staging". You
seem to think that rebasing/merging is trivial and straightforward, but
unfortunately it's not, specially if you don't understand the code well.
And some changes are just too intrusive, specially at this early stage.
For instance: according to Joel's work log, it took him about 6 hours to
rebase the 'pln' branch off of 'staging'.

Bottom line: sorry, but your suggested policy doesn't scale. It means
that 1 developer has to merge code from N others. Whereas, with
David/Cassio's policy, it scales because N developers have to merge from
1 branch.

> Sooner or later, everybody who is writing code for opencog
> needs to resolve thier changes against the main branch.
> When they are done resolving thier changes, they push
> to main.  If you are using bzr correctly, for example,
> using "bzr rebase" instead of "bzr merge", this should take
> just about one minute a day, and you should be having
> exactly *zero* conflicts.

I'm sorry again but sometimes it is just not that simple. I've rebased
your code from 'main' when I was still developing the 'dynmod' branch
and sometimes it took a long time. I had to learn a bit of the 'guile'
API; I spend a long time to finally figure out that a segfault I was
getting was due to a threads-related guile bug that was only fixed on
guile >= 1.8.4; plus several other minor problems.

Whether the time I took to get those fixed is due to my incompetence is,
of course, up to discussion but I suggest you to try it first and see if
it really is as fast as "about a minute or two a day".

> The only way that conflicts can occur is if two people edit
> the same file at the same time, and fail to rebase often
> enough.  Conflicts can be resolved by exchanging email,
> for example, you asked me not to commit any changes to
> the directory "atomspace" any more, and so I have not.
> 
> I'd like to point out that I have been waiting for many
> months for you to merge your code back in, and you still
> haven't.   It is unfair of you to make such a request, and
> then make me wait for months. I, too, wish to change
> code in that directory. I do not want to have to wait months
> to do so.  I believe that  rebasing daily or weekly would
> help resolve this kind of conflict!

Well, I'm sorry but I have no recollection of that. A *very* long time
ago, I remember having asked people to not commit for a while so that
the code style changes could land, but we were still using *subversion*
at the time. And the request for the freeze was lifted a short while
afterwards. I have also a vague recollection of *someone else* (David?
Cassio?) asking people to refrain from making intrusive changes to the
atomspace API because it would break the petaverse port, as they depend
on the current API. But I'm not even sure if this was on the
mailing-list, or irc or a face-to-face meeting here.

Anyway, commit to the atomspace directory if you must, but please make
sure you do so on the right branch (again:
lp:~opencog-dev/opencog/staging) and if it is something large, please
discuss the change with us first as we (or rather, the Petaverse guys)
might have to revert it if it breaks their stuff.

--
Gustavo