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

[Bodo Bergmann]

A project is a project, but once it is finished,
the results should go into a release - and the follow-up releases -
if it stays just a project forever I don't see a reason to keep up with
head-rev at all.

So, the ProjectD results "D" should go into CR1.
And if the CR2 codeline is branched, it should also have "D" in it,
and then there is ProjectE - it's results "E" should also go into CR2,
so when CR3 is branched it should contain Ingres+D+E.

This is only possible without a common trunk -
or with repeated cross-integration or merges.

The latter option would be like a car manufacturer planning to build a
new car model,
but they start again with the old base model when doing the planning -
the features added to the last model are not taken into account,
as you can always manually add these features later
(probably more expensive if you add the costs),
or somehow tune your old car with features developed for the new model
(most customers would still consider it an old model).


-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Daryl Monge
Sent: Tuesday, July 01, 2008 12:30 AM
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Subject: Re: [os-infrastructure] Re: [os-engineering] Closed source
components

We clearly do not have the same mental model of these  
processes.   :-)   You don't build branch "CR1" with "Project D  
support".  You cross-integrate head-rev changes into the Project D  
branch and build Project D.  You could even cross-integrate changes  
from branch "CR1" into branch "Project D" but I don't see the  
advantages to using such a process. (It would be a valid process  
however.)  If I had a special project I would just keep pulling  
changes I wanted from the head-rev into my project.

Project D is, well Project D.  Its branch is completely self  
contained.  It is NOT cross-integrated into the head-rev and therefore  
will not be cross-integrated into stable code branches as described in  
CR1.

Definitely a fun scenario to analyze........   Even useful


On Jun 30, 2008, at 5:08 PM, Joe Abbate wrote:

> Daryl Monge wrote:
>> Stable releases would be created as a branch from the head-rev much  
>> like our Piccolo release branches are done and binaries  can be  
>> build from them.  I have seen that described in several previous  
>> messages and it is in the wiki diagrams.  In
http://community.ingres.com/wiki/Image:Branch-strategy-1.png
>> It is called CR1 and CR2.
>>
>> The head-rev is source only, or possibly with nightly builds on  
>> select platforms, and can be downloaded by community developers to  
>> do whatever.  Big projects might wish to create branches early on  
>> in the project.  Again, I consider these things to be process  
>> questions, not strategic questions.  They would be needed for  
>> either scenario.
>>
>> I don't see it as being any different process than our internal  
>> systems process of creating "ingres2006r3" or the various labels  
>> used for patches.
>
> In order for someone to build a release from say, CR1, with D  
> Language support that is in, say, the PROJD branch, the relevant  
> changes from PROJD *have* to be part of CR1, i.e., they have to be  
> cross-integrated, or merged into CR1.  In other words, although the  
> changes "stay" in the PROJD branch, they're also part of CR1.  Any  
> fix made to PROJD has to be merged again to CR1 and vice versa.   
> When CR2 is ready to be created, if PROJD isn't part of the Main  
> Community Mirror, as exemplified by the downward pointing arrows  
> from the CDBn branches, the PROJD branch will have to be *again*  
> crossed-integrated or merged into CR2.
>
> Joe
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure

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