Hi,
One of the major benefits of DVCS is easy branching, and there should
be a good reason for a policy that strongly discourages branches.
What is that reason?
I can quickly think of numerous reasons in favor of branches. For
instance, Joel's work involves lots of changes to lots of different
parts of the code. The natural way to do this is by branching and
merging once all changes are completed and tested. This is true for
any such change, even if the resulting branch would be short lived.
Discouraging branches for this kind of thing encourages people not to
commit their work.
Also, based on Novamente's development history, one can expect that
many OpenCog macro-tasks will require extensive fiddling with
different aspects of the codebase, often in unexpected places. While
it's certainly possible to perform all these experiments within the
main trunk without breaking anything, that's not the most likely
outcome. The most likely outcome is that breakage from experimental
work will happen often if the default policy is to work directly from
main. This is especially true for AI researchers / scientists who
aren't experienced software engineers, yet can be invaluable for
OpenCog. In this regard, OpenCog development is very different from
regular software development, and I think our policies have to
consider this.
Finally, the "everyone works directly from main" means we have
essentially no gatekeeper to decide what gets merged into main, and I
don't think this is a good idea, at least now and in the short term
future.
I believe we need a set of practices and guidelines for development
and merging in order to minimize breakage, overhead for maintainers,
and overall frustration. But I'm not sure these guidelines should be
single-branch-based.
- make a temporary 'stable' snapshot branch of main
- merge major work branches into main (at least thee of these:
Gama's
work, Joel's work, Erickson's work)
- together, hammer on main until everyone is happy with it again
On a more detailed note, shouldn't it be the other way around? Keep
main "stable" and have an unstable branch where stuff is merged onto,
and then ported over to main? I.e., don't break the main build.
- exceptions (i.e. new branches) should be discussed here or
#opencog
- EVERY new branch should be preceded by a wiki page that
describes its
location, purpose and plan for merging back into main
I believe these are good ideas with a bit of flexibility. First, I
think branching should be the default. But I think every branch
that's expected to be merged back into main should be announced here
or #opencog and documented in the wiki.
We should meet briefly once per week on IRC just for status, notice of
upcoming merges, gripes, etc. I suggest the 15 minutes before Ben's
OCP
tutorial each Wednesday tutorial at #opencog-dev (can be created ad-
hoc).
And this, definitely, is a great idea.
Cassio
_______________________________________________
Mailing list: https://launchpad.net/~opencog-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~opencog-dev
More help : https://help.launchpad.net/ListHelp
