[os-infrastructure] Re: [os-engineering] Model discussion boiled down

[Joe Abbate]

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