[SciPy-dev] [scikits] openopt SVN instable for the moment
Wed Apr 9 08:44:05 CDT 2008
Matthieu Brucher wrote:
> > Yes, I would like to use this, but for several _months_, you did
> > nothing in that matter.
> You should just inform that something IS NOT WORKING AT ALL, while you
> had said that something works in other way than you desire only.
> I was not the only one to tell you that your system was broken. Wat I
> coded WAS NOT ACCESSSIBLE AT ALL, as you said you would do. I tried it
> several times, and when I saw that you didn't do the changes you said
> you would do (09/12/2007), I did them myself, and this time correctly.
I propose you that time to do, but you had said you don't care, you can
work with this in your way - OK, so I had switched to other tasks.
> You just told us that we had to wait for you to have financial support
> to do so. I agree that I should have been less careless.
> > Breaking my own code in the process. I didn't say a thing
> because you
> > were so busy.
> Ok, that means that anyone could commit whatever he want and say "I
> implemented my own changes to svn and I haven't informed you, because
> you are too busy!"
> No, but I'm a maintainer of this package as you are. You broke the
> import of a part of the scikit, and you didn't bother to fix it, even
> if you said you would do so.
I was insisted to include genericopt code to spread it along with
openopt. From the very beginning I wanted to reject the idea from my
mentors, and finally, as I understand, merging genericopt to openopt had
been argeed PROVIDED genericopt remains separate package. Alan G Isaac
confirmed: genericopt WILL remain separate package, available for
SEPARATE download and usage w/o OpenOpt.
But now I see that you (and mb some other scipy developers?) had
understood the situation in other way.
> > Perhaps then you should start listening to what I'm saying for
> > months ?
> there are lots of people saying me different things what OO should
> like. I CAN"T satisfy all those opinions because they are just
> CONTRADICTORY, and because I have my own point of view what OO
> should be.
> Well, as I have recalled you, we are both maintainers of this package,
> and this is not what OO should look like.
So, as I have forseen and mention in scipy mail list, this is what
sooner or later should be happen. W/o strict clarification about code
rights there are no single center of making solutions.
> This is how OO must look like : a clean and correct package that does
> not mess with people's installation.
I hadn't obtain any pretensions (except of yours, of course) about OO
installation for a very long time. And noone said me it leaks "clean" or
> > They don't do anything with OO code. Please read what I'm saying.
> > They will add by themselves in the registry (not modifying openopt
> > code) the name of their wrapper. NOTHING ELSE.
> Any people could connect their solver without any regardless to your
> changes done. There were no needs of creating any registry, anyone
> just put his _oo.py file into /solvers folder, and use his solver, and
> submit his solver(s) (_oo.py files) to openopt svn.
> Not everyone can do this. Not everyone wants to do this (because they
> installed openopt in their /usr/lin folder for instance). Give them an
> efficient way of contributing to the package. BTW, this is not
> something I did for fun, it was the only solution available to fix
> OO's design.
I don't see any problems with previous version. Anyone can download OO,
add his _oo.py-file to a directory from /solvers, run "python install"
and select any path that he want. Also, anyone could add his code to
svn/.../solvers, I didn't mind. If it's not enough for someone, for
example for you with GenericOpt, you can spread it as a separate scikit,
as I had proposed you to be done (09/12/2007) - btw, in cost of
spreading it along with OO (you could have separate tarball and/or
svn/scikit directory for genericopt).
> > I'm just worried about code I promised several people to give to the
> > community.
> Ok, suppose I'll promise to my dept to change "lil_matrix" to
> so it means i can commit my changes w/o asking permission of
> Natan? Just
> because I (+, optionally, "some people", or even "most of people")
> consider these changes to be good?
> No, because you are breaking the API. I did not break your API.
So all problems are in API only? Ok, suppose I had promised to some
people to use some fortran code instead of C or wise versa, for to
increase sparse lib speed or any other matters. So it gives me right to
delete some Nathan's C files and put my Fortran files, with possible bugs?
> > And now, with my fixes, everybody is happy,
> I'm not, and it's already enough for your statement to be 100% False
> You are not happy because you didn't want anyone to provide the
> necessary fixes to your design. Happy means that OO works the way it
> does before my fixes.
As situation with ALGENCAN shows, it doesn't
> Beides you blame me for mistakes you have made.
> I will stop answering you now, because this is useless. I'm also a
> maintainer of this package and I did not break anything in OO. I only
> refactored some code that you did not want to refactor for some
> obscure reason (so that I do not want to contribute more to the
> package perhaps ?)
I don't mind, I have enough my own intended work to be done and mb bugs
to be fixed, instead of spending time for someone's else.
More information about the Scipy-dev