Geeeee. MC is not any project, it is our key infrastructural element. So we must control it. Because it took us a lot of energy to build our infrastructure: I remember 3.9 endeavor.
>> 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. > > 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) this is totally wrong. You can take our code and port it back to anything you like. All our code is 100% MIT so what? Some people are also just stealing/copying our ideas but this is life. > The clearest example of this continues to be Monticello. It is not since MC is not any project, it is our key infrastructural element. So we must control it. > 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. keith are you telling me that I did not give to this community. Frankly? Are you serious? or blind? I will not make a list of what I did and I'm doing because I do not do it to enumerate it in public. > 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. But of what are you talking? That you introduced traits support and atomic loading on MC and that we do not consider it? But you know several people privately asked us not to include your code. So we pay attention. When I took the time to give feedback on kernel extensions or rio this was because I considered your work and I wanted to help you improving your code. But you can also think that I was whatever you want. > 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. Do you think that I'm rude because I reply to you or when I do not reply? > 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, this has nothing to do with snobbery. This has to do with freedom. You as anybody else on this earth cannot get a free check with what we are doing. You saw how we worked with the settings and preference discussion with alain. I like that way of doing things, we discuss and learn from each other. This is one solution and first it should work well in pharo. Of course this may not scale for more complex projects. > when the option and invitation is completely open for you to > participate and make it as likeable as you wish. I do not ask for that. I do not see why I would have the right to come and change think in your project. > 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 Probably. Now if we do not like the code quality we will not use that. This has nothing with snobbery this has to do with credibility on the long run. > 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. Do it if you need, we will just not use it. Note that some people do not like rio design, so the fact that it is MIT does not mean that we will use it. I looked at it because files are so bad in Squeak. Now I can understand your frustration but there are few stuff I can do. I do not have the time to do all the things I would like to do. Stef _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
