opencog-dev team mailing list archive

["Joel Pitt" <joel.pitt@xxxxxxxxx>]

Hi,

I prefer to keep separate branches from main.

The reason is that I'm experimenting, and if we DID start hacking only
on main, then my tendency would be to just keep my separate local
branches offline - hacking and rebasing till those are solid before
merging. By putting the branches on launchpad though, it allows for
people to see the changes and participate in the larger
projects/changes should they have the inclination.

A lot of experimentation/code isn't suitable for the main branch, but
being able to use Launchpad for collaboration is still helpful.

I think that a wiki page describing branches would be a good idea
though. There is also a white board for each branch on Launchpad, so
perhaps we should make better use of that to make it least cryptic
about what project a branch is related to.

J

On Wed, Sep 17, 2008 at 8:20 PM, 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~opencog-dev
> Post to     : opencog-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~opencog-dev
> More help   : https://help.launchpad.net/ListHelp
>