[os-infrastructure] Re: [os-engineering] Model discussion boileddown

[Alex Hanshaw]

svn codelines flow problems are avoided for piccolo integration if
svn-main is in lockstep with main and community branches are managed by
the community in the community (with out assistance of course).

 Alex

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Joe Abbate
Sent: 25 June 2008 14:03
Cc: Open Source Infrastructure
Subject: [os-infrastructure] Re: [os-engineering] Model discussion
boileddown

Stephen Ball wrote:
> Two comments:
>
>  - Customers are almost certainly paying us for the support and
patching
> we provide on our certified binaries, even availability of GA code
will
> make very little difference to that. Whether a customer decides to pay
> us for Support is unlikely to be affected by what source code we give
> them, and is hardly even a consideration in this equation.
>
>  - One other disadvantage of the "fresh" model is that it is
complicated
> to code and maintain. We either:
> 	1) work a "two phase commit" model on Piccolo and SVN, which
> means a Subversion crash means piccolo is not available (or
vice-versa)
> 	2) Work an "immediate" replication model, which leaves us open
> for collisions, although unlikely.
> 	3) we do "two phase commit" when we can and fall back to
> deferred when one of the systems is down, in which case we have to
code
> a way to "catch up".
>   

In my mind, the fresh model implies the following:

(piccolo)
main --------------------------------------------------
\ \ * \
---- 2006r2 --- \ \
--- 2006r3 --- \
--- 9.4 --

(svn)
main ---------------------------
\ \
--- c9.4 \
--- c9.5

The * is the point at which svn is branched from Piccolo main. From that

point forward, every change submitted to p-main would have to be 
committed to svn and every svn-main change would have to replicated back

to p-main. Currently p-main is used to cross-integrate changes from many

different codelines not shown in the diagram, e.g., if SE has to apply 
an oping20 fix to ingresr30, they usually have to integrate via p-main, 
even if the relevant feature is no longer supported in current releases.

On the Subversion side, I think svn merge allows integrations without 
passing through the trunk, but otherwise you have a reverse flow
problem.

An alternative scenario is to use a buffer branch/codeline:

(piccolo)
main --------------------------------------------------
\ \ \ \
-- 2006r2 -- \ \ \
-- 2006r3 --\ \
\ --- 9.4 --
---svncopy---
(svn)
main ---------------------------
\ \
--- c9.4 \
--- c9.5

Although it would require some additional manual intervention, I think 
it lessens the impact of implementing the synchronization and more 
importantly the almost inevitable problems that will arise in actual 
use. Furthermore, if not all platforms or not all features are to be 
included in the Community Edition, the "svncopy" branch need not include

all the main tree, e.g., if Spatial or VDBA or alpha!cl are not to be 
included, it's easier to control in a Piccolo branch. If nothing else, 
the buffer codeline can be used as an initial sandbox for 
experimentation, until we're comfortable with the idea of continually 
synchronizing the two main branches.

Joe
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure