opencog-dev team mailing list archive

["David Hart" <hart@xxxxxxxxxxxx>]

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

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

For reference for this thread, everyone should re-read (and edit or comment
as pleases you!) http://opencog.org/wiki/Development_standards and add their
branch to http://opencog.org/wiki/Branches (we'll format/organize this page
later).

-dave

On Thu, Sep 18, 2008 at 10:20 AM, Cassio Pennachin <cassio@xxxxxxxxxxxxx>wrote:

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