opencog-dev team mailing list archive

["Linas Vepstas" <linasvepstas@xxxxxxxxx>]

2008/10/27 Gustavo Machado Campagnani Gama <gama@xxxxxxxxxxxxx>:
> 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?
>
> 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.

Wow.  Its up to me?

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

You want me to be the chief maintainer? I get to
cherry-pick whatever I feel like, and put it into main?
I'm speechless, I think I misunderstood the whole
thread, I thought it was going in a completely different
direction.

I was assuming a process would include a number of
people, and not just me.

I was not asking to be appointed as gate-keeper;
that was not my intent.

I was just hoping to get a process in place where
everyone would be responsible for their own changes,
and not one where I'd be responsible for everyone's
changes.


> 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?  We're going
to have to work together pretty closely to pull this off.

> The link you're probably after is https://code.launchpad.net/opencog.
>
> The ~25 branches are still there.

Yes. That list used to be visible on the main page,
but some sort of changes made it disappear;
I was clued in on IRC about it :-/   I'm thinking
that launchpad  makes sourceforge look pretty
good in comparison.

>  I can't do anything about branches
> from other people, though.

OK. One branch at a time, then. I guess the
implication is that I should merge your branch first.
That works for me.

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

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

Well, I'd prefer that they'd email me directly, in that case.

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

Heh. Little did I know.  And despite my mistake, perhaps
as punishment for it. you now want to put me in charge of
everything?  Heh. I am such an idiot.

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

I'm sorry. I truly misunderstood, this has been a major
miscommunication, I am sorry, and in shock.

I honestly did not know of its existence, and I utterly
failed to understand what you were asking me to do.

> 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. But if instead, I get
to cherry-pick through everyone's trees,
I don't see how that is going to be more scalable.

If there are merge difficulties, maybe I can resolve them
quickly and maybe I can't.  If I can't resolve them
easily, then that code suffers.

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

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.

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

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

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

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.

--linas