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

[Ted Ralphs]

I'm switching this thread over to the OSI and TLC mailing lists in
order to avoid spamming all the other PMs.

Yes, especially now that we are trying to decouple releases cycles, I
think it makes sense to think about having the OsiXXX for solvers in
COIN moved to each project's repository rather than having them all in
the Osi repository. It's always been a bit of a strange fit to have to
make changes in Osi to update SYMPHONY's interface, for instance.

The only sort of tricky piece I see at the moment (thought there are
bound to be others) is related to the discussion that's been on-going
for years vis a vis unit tests and circular dependency. Osi has to
depend on Clp and/or some other solver to make any kind of sensible
unit test. But now it looks as though Clp will also depend on Osi. I
guess that the way around this is what was suggested---don't make Clp
dependent on Osi. Just make the configure script only build OsiClp
when Osi is present. Then all externals remain the same as they are.
Thoughts?

Can we implement and test this change during the BSP using only BSP
versions? It seems so. John, would this address your concern
adequately?

Cheers,

Ted

On Sun, Jul 5, 2009 at 11:55 AM, Stefan
Vigerske<stefan at math.hu-berlin.de> 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.
>
> 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
>
> _______________________________________________
> Project-managers mailing list
> Project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/project-managers
>



-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted