[Project-managers] BSP 2009 and changes to project management procedures

Stefan Vigerske stefan at math.hu-berlin.de
Sat Jul 4 08:27:33 EDT 2009


Hi,

> I think what John suggest is a reasonable compromise. trunks use 
> stables as externals, stables use releases as externals.
> 
> What do others think?

I think Ted once said that trunks pointing to stables can be used as
exception, but the general idea is to have trunks point to releases.
I would say that John with Cbc/Osi/Clp can be such an exception :-).

Stefan

> 
> --Laci
> 
> On Sat, 4 Jul 2009, John J Forrest wrote:
> 
>> Laci,
>>
>> I had come to the same conclusion overnight.
>>
>> I am going to make my trunk point to a stable version.  The stable version
>> itself should point to releases for externals.
>>
>> 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.
>>
>> John
>>
>>
>>
>>  From:       ladanyi at watson.ibm.com
>>
>>  To:         Lou Hafer <lou at cs.sfu.ca>
>>
>>  Cc:         project-managers at list.coin-or.org
>>
>>  Date:       07/03/2009 02:05 PM
>>
>>  Subject:    Re: [Project-managers] BSP 2009 and changes to project management procedures
>>
>>
>>
>>
>>
>>
>> Hmmm...If we got to choose between the current way and having the
>> releases as externals I would certainly go for the releases. But can
>> we have stables for externals? Or would we loose many of the benefits
>> that having releases as externals gives? I have not really thought
>> this through, I just thought I would float the idea...
>>
>> --Laci
>>
>> On Fri, 3 Jul 2009, Lou Hafer wrote:
>>
>>> Folks,
>>>
>>>            I share John's concerns here, and mine extend beyond Osi.
>> Past history
>>> says that improvements often require simultaneous changes to multiple
>> projects.
>>> Our current procedure provides a lot of implicit testing and
>> communication
>>> through trunk development.  It also brings moments of acute pain as we
>>> synchronise releases to work through a new release cycle.  No news here,
>> I've
>>> written this before.
>>>
>>>            I can also see the need for RPM packaging for standard linux
>> distros,
>>> and I can see how difficult this is in the present tightly-coupled
>> system.  A
>>> policy that one project depends only on releases of other projects will
>> really
>>> help here.
>>>
>>>            I have lots of reservations.  But mostly, I'm assuming that
>> the
>>> technical pros and cons have been debated into the ground by the TLC and
>> the
>>> conclusion is that, on balance, we'll be farther ahead with this change.
>> No way
>>> forward but to give it a try.
>>>
>>>
>>       Lou
>>> _______________________________________________
>>> Project-managers mailing list
>>> Project-managers at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/project-managers
>>>
>> _______________________________________________
>> Project-managers mailing list
>> Project-managers at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/project-managers
>>
>>
> 
> _______________________________________________
> Project-managers mailing list
> Project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/project-managers
> 



More information about the Project-managers mailing list