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