Hi -
Thanks everyone for the reasoned and civil responses. It is good to see
that we can have a disagreement without getting overly personal.
Unfortunately, it seems that I'm effectively offered a no-win
alternative here; I do not see how any of the discussed alternatives
would help me achieve my goals. I will have to think about where to take
things from here. If anyone has ideas, please let me know.
Cheers,
- Andreas
On 8/30/2010 12:57 PM, Nicolas Cellier wrote:
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<marianop...@gmail.com>:
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.
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
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
