2009/3/20 Stéphane Ducasse <stephane.duca...@inria.fr>: > Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is. > > Igor I think that the point of keith was not about that goal (even if > his process > implies been able to plant new trees everywhere and not cutting that > much rotten trees).
Well, i tried to describe your motives, as i see it, to show that often its not possible to build a new thing without breaking an old one. Again, as i said, lets say you improved/changed the package X to suit your vision, and this package is no longer maintained by any other party. So does it makes such change evil of some sort? I don't think so. Consider a Morphic. Can anyone tell who is maintaining it? No one! Gary did a lot of hard work balancing between good and stinky code trying to improve things in his Polymorph package without breaking things in Morphic. Now think, how easier/faster it would be it we would have an official Morphic package/module and official maintainer(s) who continuously improving the code & maintaining it. > I think that keith was frustrated that we could give feedback or > threshold for > package inclusion in pharo and that he worked on them and that we > neglected > them. > Now everybody has the right to stand up for or against a package and > make a point. > Of course stating publicly that a given piece of code is great is > easier than the inverse > especially when you want to pay attention to the human at the other > end of the line. I think you have a full right to decide what [not] to include in Pharo. Keith mentioned that you making many changes to many different parts of system , which supposed to be maintained by original authour(s) or currently active team(s), without giving a feedback or credit or consulting with them about promoting such changes. Okay, i think you're not stepping into other's domain.. it would be rude.. But its going to be tricky, when you change the package X (not maintained by anyone), from which depends a lot of work, which doing in parallel by other team for package Y, which depends on X. Here lies the problem, which can be solved by communicating with people. Of course it requires the good will of both sides :) > Stef > > On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote: > >> 2009/3/20 Keith Hodges <keith_hod...@yahoo.co.uk>: >>>> >>>> I have nearly 20 years of brain cells now if I do not die before >>>> so I >>>> do not want to >>>> spend my time on boring stuff when I can avoid it. >>>> >>> But you are throwing the baby out with the bath water. >>>> No but we have the right to choose and consider if we like it or >>>> not. >>>> >>>> >>> Actually I disagree. >>> >>> You are mixing two completely different things here. >>> >>> 1. Squeak, an open source project with lots of stake holders that may >>> cramp your style. >>> 2. Any other completely open sub-project which you are invited to >>> contribute to and further your aims by participating with (i.e. >>> Monticello) >>> >>> When you forked pharo you understandably forked 1. There was no >>> need to >>> fork any external projects (2) >>> >>> Every sub-project (2) has its own developers, and its own culture, >>> and >>> attitude towards participation and change. When you treat other -sub >>> projects and their communities with the same contempt that you >>> understandably have towards the squeak community, you result in >>> insulting those communities. >>> >>> The initiative I started on MC has a culture of participation and >>> collaboration, together with an ethos of being as responsive as >>> possible >>> to feedback and suggestions. When you ignore this, you insult >>> everyone >>> that has put time and effort into that project. >>> >>> In a similar manner, any initiative or sub-project that you undertake >>> within pharo, can have an ethos following either of two options. >>> >>> A). Pharo team specific developed for pharo speced for pharo only. >>> B). A completely open sub-project which anyone is invited to >>> support and >>> to further your aims by participating with. >>> >>> When you pick option A, or fork option 2, you are actually insulting >>> every project that was offered to you on the basis of option 2 above. >>> Because you are saying, that you are happy to take from the other OSS >>> efforts but you are not happy to give back, or contribute back to >>> them >>> on a similarly open basis. (and "you can port it if you want it" >>> doesn't >>> count) >>> >>> The clearest example of this continues to be Monticello. >>> >>> When I do months of work and suffer considerably for the good of >>> "everyone that wants change" of which you were one person at the >>> top of >>> the list. I do the work out of the goodness of my heart because I >>> expect >>> in the ethos of open source software that there is some give and >>> take. >>> "Take" because I build on the work of others that freely >>> contributed to >>> me, and "give" because I contribute to the furtherment of the vision >>> that they started, and "take" again because I anticipate others >>> continuing the good fight in the long run on everyones behalf. >>> >>> Given a completely open independent project, that you are invited to >>> support and contribute to, on which much work has already been done >>> "on >>> YOUR behalf", in the direction of "YOUR goals". I consider it to be >>> extremely rude and insulting, for you not to join in and further your >>> own aims by contributing positively back to that project. >>> >>> The reason that I have no interest in participating in pharo, is not >>> that I dont agree with the vision. Its the fact that I find the >>> attitude >>> of the pharo team (with a couple of notable exceptions) to be >>> extremely >>> rude. Perhaps its a cultural thing. >>> >>> I consider the attitude conveyed by the words "No but we have the >>> right >>> to choose and consider if we like it or not." to be tantamount to >>> snobbery, when the option and invitation is completely open for you >>> to >>> participate and make it as likeable as you wish. >>> >>> It is perfectly possible for the following projects to be initiated >>> as >>> loadable modular sub-projects, developed with an ethos of >>> participation >>> for anyone to contribute and for anyone to use. >>> >>> 1. Registration for menus and UI features >>> 2. Improvements to Streams >>> 3. HTTPSocket >>> 4. Alternatives to Changesets >>> 5. Replace the changes file mechanism with something else >>> 6. Atomic loading (including traits) >>> 7. Replacements for Morphic, MVP >>> 8. Compiler >>> 9. Network. >>> 10. Compression. >>> 11. Files >>> 12. SSpec >>> 13. SUnit >>> 14. Code Browsers/Tools >>> >>> I am seriously considering licencing Rio under something other than >>> MIT, >>> so that you cant use it, until you change your attitude towards your >>> potential benefactors. >>> >> >> There is one problem with Squeak, that it grew out to something >> amorphous, up to the point that its really hard to tell where ends one >> package/module and starts another one. >> I sense the future of squeak is to make a cleaning to cut-out many >> interdependencies, for getting to the point where all code is clearly >> falls into separate modules. From this point, different modules can be >> improved separately, but not sooner. And Pharo team is doing a lot for >> making this happen. >> For example, i wouldn't buy the Compression framework which fails to >> work without Morphic/Etoys. And i don't think that making sure it >> doesn't have such interdependencies is a rude. I think its rude to >> keep thing in such state by honing the swamp which equally sucks the >> energy from everyone and suppressing progress. >> >> You can't plant the wheat in the forest, first you have to cut down >> the trees and get rid of stumps. >> I think its too early to say that Pharo went too far from Squeak to >> make it hard to backport any changes/improvements. I appreciate >> Stephane's attempts to chop down some old rotten trees in forest to >> make more space for growing a new sprouts. >> >> There's another aspect of same thing: a lot of Squeak code/packages >> having no maintainers. >> People expect that someone takes care of code which is released with >> image. But let us be realistic: there is no such developers/teams who >> could take a grasp of such big code base and maintain it. >> And there is choice: keep using old code (mostly w/o changes), >> sacrificing the potential of having a lot of code bloat, or cut it out >> and then reintegrate/reimplement it in a more modular style. >> >>> Keith >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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
