[SciPy-dev] [scikits] openopt SVN instable for the moment

[dmitrey]

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
>     several
>     > months ?
>
>     there are lots of people saying me different things what OO should
>     look
>     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,
above
> 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 
"correct".
>  
>
>     > 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
>     could
>     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
>     "sparse",
>     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.

D.