Hi Pharoers, I'm happy to read mail from Torsten, Igor and Miguel, thank you guys that's constructive. Andreas expressed his point very well, and i don't think it is hostile, maybe a bit sarcastic or disenchanted, but overall he keeps the door opened. The first thing to do is to cool down, relax and think. The second thing to do is engaging discussion with Andreas. Of course, the license is of prime importance, not having a license is a showstopper. If license is too restrictive then Andreas will probably fail to reach his goals... There will be de facto full rewrite rather than forks, but the net result will be the same: failure to share packages/libraries. That's why I personnally don't find Andreas defensive position a good strategy. Neither the attitude in response... It's like you're happy to throw his work away at first occasion without even trying to negociate. Bad vibrations. Before you engage in this (war)path, please, please, discuss. And remind this saying "il ne faut pas confondre vitesse et précipitation". If no agreement is found then, ok, you'll get a license to carry on. After the license problem, there is the technical compatibility problem. Discussions about cross fork compatibility, compatibility layers or libraries (a la GREASE) will have to occur anyway, be it about Andreas library or from any other author. So you'll have to take time to discuss. Don't consider this as lost time. These discussions are considered necessary when they regularly happens in Pharo mailing list, aren't they ? It shouldn't be that hard to convince Andreas to change things like and:and:and:. For squeakToUtf8, I don't know, maybe provide some automated rewrite rules, and produce an automated Pharo version ? Please, discuss, argue, explain why you consider certain constructions as bad style. Propose alternatives (be constructive - remember coopetition ?). I consider being unable to explain one's own choice as a weakness. Don't be weak. Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Nicolas 2010/8/30 Mariano Martinez Peck <marianopeck@gmail.com>:
2010/8/30 Miguel Enrique Cobá MartÃnez <miguel.coba@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.
Agree with Miguel. It is the smae situation as Gofer. Lukas is the main developer of Gofer but we (pharo developers) maintain it. When a message is removed or renamed for example, we take care about its senders, for all packages, included Gofer. And we are the responsible, not Lukas.
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.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project