<html><body>
<p>Laci,<br>
<br>
I had come to the same conclusion overnight.<br>
<br>
I am going to make my trunk point to a stable version. The stable version itself should point to releases for externals. <br>
<br>
That will mean that a trunk will not depend on totally untested stuff in another trunk, but at least the code is thought okay for stable. Also pointing to a version would mean that I could update OsiClp in stable without having to get Lou involved.<br>
<br>
John<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for ladanyi---07/03/2009 02:05:23 PM---Hmmm...If we got to choose between the current way and having the"><font color="#424282">ladanyi---07/03/2009 02:05:23 PM---Hmmm...If we got to choose between the current way and having the</font><br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">From:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">ladanyi@watson.ibm.com</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">To:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">Lou Hafer <lou@cs.sfu.ca></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Cc:</font></td><td width="100%" valign="middle"><img width="1" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">project-managers@list.coin-or.org</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Date:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">07/03/2009 02:05 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2" color="#5F5F5F">Subject:</font></td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBFF7ADFBCCB788f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">Re: [Project-managers] BSP 2009 and changes to project management procedures</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt>Hmmm...If we got to choose between the current way and having the <br>
releases as externals I would certainly go for the releases. But can <br>
we have stables for externals? Or would we loose many of the benefits <br>
that having releases as externals gives? I have not really thought <br>
this through, I just thought I would float the idea...<br>
<br>
--Laci<br>
<br>
On Fri, 3 Jul 2009, Lou Hafer wrote:<br>
<br>
> Folks,<br>
><br>
> I share John's concerns here, and mine extend beyond Osi. Past history<br>
> says that improvements often require simultaneous changes to multiple projects.<br>
> Our current procedure provides a lot of implicit testing and communication<br>
> through trunk development. It also brings moments of acute pain as we<br>
> synchronise releases to work through a new release cycle. No news here, I've<br>
> written this before.<br>
><br>
> I can also see the need for RPM packaging for standard linux distros,<br>
> and I can see how difficult this is in the present tightly-coupled system. A<br>
> policy that one project depends only on releases of other projects will really<br>
> help here.<br>
><br>
> I have lots of reservations. But mostly, I'm assuming that the<br>
> technical pros and cons have been debated into the ground by the TLC and the<br>
> conclusion is that, on balance, we'll be farther ahead with this change. No way<br>
> forward but to give it a try.<br>
><br>
> Lou<br>
><br>
> _______________________________________________<br>
> Project-managers mailing list<br>
> Project-managers@list.coin-or.org<br>
> </tt><tt><a href="http://list.coin-or.org/mailman/listinfo/project-managers">http://list.coin-or.org/mailman/listinfo/project-managers</a></tt><tt><br>
><br>
<br>
_______________________________________________<br>
Project-managers mailing list<br>
Project-managers@list.coin-or.org<br>
</tt><tt><a href="http://list.coin-or.org/mailman/listinfo/project-managers">http://list.coin-or.org/mailman/listinfo/project-managers</a></tt><tt><br>
</tt><br>
<br>
</body></html>