opencog-dev team mailing list archive

["David Hart" <hart@xxxxxxxxxxxx>]

The simple answer is that OpenCog is not yet an 'enterprise-level'
application; rather, it's analogous to a pre-1991, pre-0.11, pre-self
hosting version of the Linux kernel.

Perhaps 'testing' is a a better name (more meaningful to onlookers) for
'staging'.

OpenCog uses many dev branches, which is the common practice for DVCS (some
branches will be for individual work, some for group work). Under this
scheme, 'testing' would be shorthand for 'integration & testing'.

Any other suggestions on a better/clearer name for the branch now named
'staging'?

I suspect however that it's impossible to please everyone with any single
workflow or branch naming scheme.

-dave


On Mon, Oct 27, 2008 at 12:11 PM, Mark Waser <mwaser@xxxxxxxxxxxxx> wrote:

>
>    What ever happened to the standard enterprise-level paradigm of dividing
> into dev, testing, main/live, and debug (for time-critical fixing and
> testing of critical problems that somehow made it past testing and onto
> main/live) with testing being pushed simultaneously to dev and main/live
> when appropriate and debug being pushed to dev, testing, and live when
> appropriate?  It looks like this mystical staging is somewhere between (or
> a
> combination of) dev and testing except that *nothing* should be ever be
> "rebased" on live because live should be static except when updated by
> testing (staging?) or debug (which also updates testing in the same fashion
> at the same time).
>
>    The "large, probably painful merge" should occur into dev, which should
> then be frozen and placed on testing, and then upon approval go to
> main/live
> and refresh dev (or, if you prefer, dev should be "rebased" upon it).
>
> ----- Original Message -----
> From: "Cassio Pennachin" <cassio@xxxxxxxxxxxxx>
> To: <linasvepstas@xxxxxxxxx>
> Cc: <opencog@xxxxxxxxxxxxxxxx>; "opencog-dev"
> <opencog-dev@xxxxxxxxxxxxxxxxxxx>
> Sent: Monday, October 27, 2008 2:48 PM
> Subject: [OpenCog] Re: [Opencog-dev] [OpenCog] Re: staging and main
>
>
> >
> > Linas,
> >
> >> 1) Staging should be rebased on main, regularly (e.g. daily)
> >
> > This makes sense once there's a policy for code making it directly
> > into main (e.g., bug fixes).  Right now, the policy is one-way, so I
> > don't really see the point.
> >
> >> I wrote code that I placed into the main branch.  The fact that
> >> its not in the staging branch tells me that no one is rebasing
> >> staging on main.
> >
> > That's because commits should go to staging, not to main.
> >
> >> I am concerned that main and staging are
> >> drifting apart, and that there will be large changes between
> >> these two, and that they will be hard to reconcile.
> >
> > Yes, I think we all anticipate one very large, probably painful
> > merge.  Hopefully it will be the only one because after that staging
> > will feed main more frequently and granularly.
> >
> >>> I believe one can create a
> >>> patch for that code, and the developer who wrote it can then merge it
> >>> with staging and fix incompatibilities.
> >>
> >> Yes, but whomever is  contributing to staging has a duty
> >> to make sure that  they are in sync with main, which is
> >> what seems to not be happening.
> >
> > That's not in the current policy.  I'm not opposed to changing the
> > policy, but under the current policy you should only commit to
> > staging, and Gama should be the only one who commits to main when
> > merging from staging or possibly for bug fixes, should we change the
> > policy to cover that.
> >
> > Cassio
> >
> > >
> >
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenCog General & Scientific Discussion List" group.
> To post to this group, send email to opencog@xxxxxxxxxxxxxxxx
> To unsubscribe from this group, send email to
> opencog+unsubscribe@xxxxxxxxxxxxxxxx<opencog%2Bunsubscribe@xxxxxxxxxxxxxxxx>
> For more options, visit this group at
> http://groups.google.com/group/opencog?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>