2010/8/30 Miguel Enrique Cobá Martínez <miguel.c...@gmail.com>: > El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribió: >> My 2 cents about WebClient. >> >> - it should be an (un)loadable external package, and i am fully agree >> with Andreas on this point. >> It is tempting to integrate it into image, do some tweaks here and >> there and then ship it within a monolitic image. >> But then, from maintainer's point of view, it is quite hard to keep >> developing it and improving, since it may break >> things in random places over multiple forks etc etc, and then who will >> be accused in such breakage? - a maintainer. > > Of course not, we, the ones using it as part of our core image are the > ones responsible of the correct functioning in our image. It would be > childish to run crying to Andreas that it break our image because we are > taking the decision of integrating it in the core image. Now, this of > course doesn't apply to core functionality or that breaks the contract > the code offers to its clients. That type of API changes will be > discussed with Andreas and if no solution found, the pharo developers > will found a workaround so that is remains working correctly. > > What I don't understand is why such imposition to the way of use the > software. If it decided to have an open source license he can't restrict > the uses of the software. This is a real open source implications. > > >> >> It is good to have a person, who personally responsible for >> maintaining a package, or even if by a group of people, >> it should use a separate repository for developing it. >> >> Otherwise, if you integrate it into image, by doing that you: >> - losing a maintainer , who willingly contributing to this project >> - in same turn, must take own responsibility for maintaining it, >> which means extra work for you, whenever you having >> problems with it. > > Of course, that is the point. Nobody expects otherwise. >
Then you making things wrong, because then: - party A made feature A available - party B made feature B available - users want A and B features both, but party A and B do not communicate I think that Andreas wants to impose a teamwork, when multiple parties working on same project, rather than multiple parties working on each own fork of a same project. I think i understood the Anreas'es point well. As initial developer, he dont wants to be in position, when his creation moves into a different direction, than he is initially planned. At least, until Andreas to-do list is not empty, and project is not mature enough, it is wise to keep development under his personal control. That's how i understood his message about license. >> >> We should learn how to integrate things without intimately tying >> everything with a single bloated image. > > Isn't as we are integrating moose or seaside in the core image is a > basic infrastructure thing, a http client, that every modern language in > the current times includes in their core libraries (java, ruby, lisp). > >> And WebClient could be right thing for learning that (Seaside too ;). >> > > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
