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

Laszlo Ladanyi ladanyi at us.ibm.com
Fri Jul 3 08:23:09 EDT 2009


Hi John,

On Fri, 3 Jul 2009, John J Forrest wrote:

>
> Ted,
>
> On thinking it over, I can see problems with trunk projects pointing to
> releases.  The main problem would be Osi.
>
> Suppose I make an improvement to Clp which I want to be available in Cbc.
> I can make a release of Clp if I want to, but there may have to be changes
> to OsiClp.  This would mean a new release of Osi which might not be
> convenient as Osi has so many solvers.

Actually, that's the whole idea :-). This way improvements get 
released more frequently. But what you suggest is a valid concern... 
How about splitting up Osi in the sense that each solver can be 
released separately? We are creating separate libraries from the 
solverinterfaces anyway... And the same problem applies to cgl as 
well...

--Laci

>
> Does anyone else see this as a problem?  I suppose I could keep a trunk and
> a branch?
>
> John
>
>
>
>  From:       Ted Ralphs <ted at lehigh.edu>
>
>  To:         project-managers <project-managers at list.coin-or.org>
>
>  Date:       06/30/2009 05:38 PM
>
>  Subject:    [Project-managers] BSP 2009 and changes to project management     procedures
>
>
>
>
>
>
> Hi folks,
>
> This e-mail is to (1) announce the 2009 Bug Squashing Party and (2) make
> you aware of important impending changes in the TLC's recommended project
> management procedures. I apologize for the lengthy explanation, but there
> is a lot to tell!
>
> 1. The third annual Bug Squashing Party is scheduled to take place July
> 7-8. For those who are not familiar with this event, it is an annual
> on-line event in which volunteers gather in a virtual chat room to fix as
> many small bugs, compiler warnings, portability issues, memory leaks, etc.
> as possible in COIN projects. By gathering volunteers with access to a wide
> range of platforms and compilers, we have been able in the past to
> accomplish a lot in a short period of time. The procedure involves creating
> a temporary copy of the most recent stable branch of various projects,
> fixing the bugs in that copy and then merging the changes (at the PMs
> discretion) back into the stable branch and/or trunk, as appropriate. More
> information is available at the Bug Squashing Party wiki.
>
> PLEASE LET US KNOW IF YOU
>
> -- WANT TO HELP WITH THE EVENT YOURSELF
> -- DO OR DO *NOT* WANT BUGS TO BE FIXED IN YOUR PROJECT
>
> By default, all projects using the BuildTools will be included.
>
> 2. As part of a multi-faceted, long-term effort to improve the usability of
> all COIN projects and ease the overall maintenance burden, we will be
> announcing over the next several months a number of changes to the
> recommended project management procedures for COIN projects. The first of
> these will be a recommendation to begin developing project trunks against
> release versions of other projects. There are many reasons for this and we
> will be providing a full explanation in the near future. In short, however,
> we would like to decouple development of independent COIN projects as much
> as possible in order to (1) reduce the impact of individual projects'
> release cycles on other projects, (2) ease the complexity of dependencies
> and make simultaneously installation of multiple projects easier on end
> users and (3) ultimately make it possible to support the development of a
> package management system that would enable easy installation and upgrade
> of COIN binary packages over time. At the moment, our procedures tend to
> couple the development of many of the projects and actually make the
> release cycle much slower. Our current handling of dependencies is also not
> very compatible with the maintenance RPMs for COIN, etc. You will here more
> about this over time.
>
> PLEASE LET US KNOW IF YOU
>
> -- WOULD LIKE US TO SWITCH THE EXTERNALS OF YOUR PROJECT'S TRUNK TO POINT
> TO RELEASES OF DEPENDENT PROJECTS AND TEST IT DURING THE BSP.
> -- PLAN ON DOING THIS YOURSELF.
>
> Of course, this is a completely voluntary step, but we are strongly
> encouraging it. Please let me know if you have any questions about any of
> this. Thanks for your support!
>
> Cheers,
>
> Ted
> --
> Dr. Ted Ralphs
> Associate Professor, Lehigh University
> (610) 628-1280
> ted 'at' lehigh 'dot' edu
> coral.ie.lehigh.edu/~ted
>
> _______________________________________________
> 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