[Osi] [Coin-tlc] [Project-managers] BSP 2009 and changes to project management procedures
Lou Hafer
lou at cs.sfu.ca
Mon Jul 6 12:38:58 EDT 2009
Folks,
Matt's idea works for me --- it has the advantage that it doesn't make
orphans of the OsiXXX that aren't tied to projects in the Coin repository.
Actually, it looks a lot like the setup for CHiPPS.
Unfortunately the timing of this year's BSP is just not possible for me.
I'll trust in your delicate touch. The BSP really is the ideal opportunity to
attempt this change.
And since I won't have to do the work --- why not do this for CGL at the
same time? :-)
Lou
==================================================
> Matt's post didn't include the TLC, so I'm cross-posting this reply in
> case anyone is interested.
>
> I don't mind this solution and it does have the advantage of making
> the management of all OsiXxx projects symmetrical. Presumably, then,
> Clp's trunk would depend on OsiClp's trunk, but on the latest release
> of Osi itself? I think this is OK, but perhaps a little confusing. The
> same could apply to Cgl...
>
> Cheers,
>
> Ted
>
> On Mon, Jul 6, 2009 at 10:40 AM, Matthew Saltzman<mjs at clemson.edu> wrote:
> > I'd like to pose a different strategy and see if it has any traction.
> >
> > What if we make the OsiXxx shims subprojects of Osi. This strategy
> > would move the shim code out of the main Osi tree and let us manage
> > maintainers, but it would not move the code out of the project entirely.
> >
> > So the Osi SVN tree would look like this:
> >
> > * OsiBase
> > * trunk
> > * stable
> > * releases
> > * etc.
> > * OsiCpx
> > * trunk
> > * stable
> > * releases
> > * etc.
> > * OsiClp
> > * trunk
> > * stable
> > * releases
> > * etc.
> > * etc.
> >
> > Each subproject can run its own release cycle. If it's tied to another
> > COIN project and maintained by that project's PM, that PM can manage
> > releases to coincide with his main project. OsiBase releases need not
> > be tied to OsiXxx releases. All the Osi code remains in a single repo,
> > rather than some being scattered to other projects.
> >
> > Thoughts?
> >
> > Matt
> >
> >
> > On Mon, 2009-07-06 at 10:07 -0400, Ted Ralphs wrote:
> >> 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
> >> >
> >>
> >>
> >>
> > --
> > Matthew Saltzman
> >
> > Clemson University Math Sciences
> > mjs AT clemson DOT edu
> > http://www.math.clemson.edu/~mjs
> >
>
>
>
> --
> Dr. Ted Ralphs
> Associate Professor, Lehigh University
> (610) 628-1280
> ted 'at' lehigh 'dot' edu
> coral.ie.lehigh.edu/~ted
>
>
> _______________________________________________
> Coin-tlc mailing list
> Coin-tlc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-tlc
>
More information about the Osi
mailing list