← Back to team overview

opencog-dev team mailing list archive

Re: merging work into opencog/main

 

Hi,

While I didn't advocate a "no branch policy" I did recommend that main
be seen as the unstable branch and that stable branches (including
"release" branches) be created from main.  My reasoning is that the
developers have stopped working together.  Instead, they work
separately then try to integrate.  Working with others is seen as a
pain, so the tendency is to simply not, and the integration gets
delayed, and delayed, and delayed.

This is a good point, we need to have more frequent integration and killing of branches. But I think the best way to foster this is just frequent communication. If people gather on #opencog once a week and everyone updates everyone else on the status of their branches, we can probably get people to integrate at the right moment.

I understand that an unstable branch is intimidating to some, as
experimentation needs a stable base, but experimentation branches can
be created from stable branches, and changes that show up on the
unstable branch can be merged in as needed.  On the other hand,
working on small changes is often best done without a branch, as
integration is the focus, and not being able to tell if your changes
will break some experimental branch means that you're offloading work
onto the experimenters, and that also makes people reluctant to
contribute.

I like an unstable branch, I just don't like it being the main branch, because then main would be constantly broken, and people who merge there don't have an incentive to make sure their changes don't break other code -- or, sometimes, wouldn't even be able to do that. I feel quite strongly that main should not be broken at any time, and people can only merge there by ensuring their changes don't break anything.

Cassio



References