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

[Matthew Saltzman]

On Sat, 2009-07-04 at 14:38 +0200, Stefan Vigerske wrote:
> Hi,
> 
> >>>> 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...
> >>
> >> I would support the idea to put OsiClp into Clp.
> >> Not making Osi a requirement for Clp, but if Osi is available during the
> >> Clp build, then also an OsiClp library should be build.
> >> Similar, OsiDylp could move to Dylp, OsiSymphony to Symphony, ...
> >> And for the Osi interfaces to solvers that are not in COIN-OR (yet ;-)),
> >> the OsiXXX might either go into a separate place (as Laci suggested) or
> >> just stay in Osi for now.
> >>
> > 
> > Hear, hear! Let's do it!
> 
> What could be the steps towards this?
> 1. Get Lou's and Matt's (whom of them is the PM of Osi?) agreement.

Officially, me, but Lou's been doing most of the maintenance recently.
I'd consider us a unit 8^).

I'm generally open to it, but a plan needs to treat the OsiXxx packages
that don't have back ends in COIN-OR (the commercial ones, GLPK, etc.)
and ones where the back-end PM doesn't want to maintain their OsiXxx in
a way that is reasonably consistent and sensible.

This also seems to mean that close coordination of releases between back
end projects making OsiXxx changes and Osi itself may be needed at
times.

Lou?

> 2. Have projects which currently still point to Osi/trunk point to the
> latest Osi/stable.

This should happen anyway, as we want to get away from anything pointing
at trunk externals, if I'm following the rest of the discussion
accurately.

> 3. Find out which projects XXX (e.g., Clp, DyLP, Vol) with an OsiXXX are
> interested in maintaining their OsiXXX by themselves.
> 4. Remove those OsiXXX from Osi/trunk.
> 5. Make a new Osi stable version and revision.
> 6. Have projects XXX add this (shrinked) Osi to their externals and add
> the corresponding OsiXXX code to XXX.
> 7. Create a new stable and release of XXX.
> 8. Have higher level projects (Cbc, Bonmin, OS, ...) use the new stables
> of XXX and Osi and change their Makefile's to pick up the OsiXXX's from
> the new location.
> 
> Stefan
> 
> _______________________________________________
> Project-managers mailing list
> Project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/project-managers
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs