[Osi] [Coin-tlc] [Project-managers] BSP 2009 and changes to project management procedures
Matthew Saltzman
mjs at clemson.edu
Mon Jul 6 14:59:40 EDT 2009
I won't be able to join tomorrow or before Wed pm either. But if you
all agree this is worth trying, feel free to test without me.
On Mon, 2009-07-06 at 09:38 -0700, Lou Hafer wrote:
> 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
> >
>
>
> _______________________________________________
> Osi mailing list
> Osi at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/osi
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
More information about the Osi
mailing list