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

[Jay Hankinson]

Yes, absolutely. If we don't merge projects back into a common codeline 
we'll just end up with a whole load of forks which isn't really much use 
to anyone. The branches simply allow the more ambitious features to be 
developed without destabilizing the current CR.

J
Bodo Bergmann wrote:
> 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
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>