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

[Stefan Vigerske]

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.

I think if we keep these OsiXxx in Osi, then we are "forced" to maintain
them when Osi itself is changing. Only for those Yyy which have a PM
that wants to maintain the OsiYyy outside of Osi - and probably inside
Yyy - it will be up to this PM to keep up with Osi developments.

Stefan

> 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