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 _______________________________________________ Mailing list: https://launchpad.net/~opencog-dev Post to : opencog-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~opencog-dev More help : https://help.launchpad.net/ListHelp
