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

[John J Forrest]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/project-managers/attachments/20090704/5ad83ccd/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/project-managers/attachments/20090704/5ad83ccd/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/project-managers/attachments/20090704/5ad83ccd/attachment-0001.gif