[os-infrastructure] Re: [os-engineering] Closed source components

[Daryl Monge]

So, if I understand the actual, fundamental strategic problem for the  
DBMS code line it boils down to:

1)  There is one head-rev for both the community edition and the  
internal enterprise edition and they are kept in lock-step as much as  
is practical (minutes? hours? days?)

2)  There are two head-revs.  Community and Enterprise.  There is a  
constant manual activity to cross-integrate changes between them.

A variation is a slight hybrid to (2) is where the Enterprise head-rev  
is kept in lock-step with community but the community head-rev has to  
be manually cross-integrated into the Enterprise head-rev.

All the other discussion seems to be completely around the details of  
handling branches/labels/releases, cross-integrations, etc. and from  
my view can be handled with either scenario.

I think (2) and its variation is too much work and fraught with  
logistical and quality control dangers.  The fallacy I perceive in the  
discussion is the notion that changes are coming into community head- 
rev that we do not want.  This strikes me as a process problem rather  
than a strategy problem.  You would no more allow changes you do not  
want into the community head-rev than you would allow someone to put  
something unapproved into the Enterprise head-rev.  There are NOT  
going to be very many ( <10?  <5?) people with commit privileges into  
the community head-rev for a long time.  Much of the discussion seems  
to be based on the notion that just any Joe or Jane developer can  
submit anything to the head-rev whenever they want.

Community editions that should never make it into the Enterprise code  
line should remain on a project branch in the community edition code  
line and never allowed to cross-integrate into the head-rev.

So I stand by strategy (1).


"Thats just my opinion, I could be wrong"
	- Dennis Miller
"I could be wrong, but I don't think so"
	- Charles Barkley



Side note:  It looks like OpenRoad as 4 head-revs instead of one.  I  
don't understand how that affects the strategy question.  It is  
perfectly reasonable not to grant anyone outside internal development  
commit privileges to one or any of them in a community repository that  
mirrors them.  At least for a while.  It may be reasonable not to even  
mirror some or most of them.