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

[Laszlo Ladanyi]

I think what John suggest is a reasonable compromise. trunks use 
stables as externals, stables use releases as externals.

What do others think?

--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
>
>