Stéphane Ducasse wrote: > Geeeee. > > MC is not any project, it is our key infrastructural element. So we > must control it. > I disagree, its key to all users of squeak. So you must ensure that it is looked after and maintained. There is absolutely no need to control it. You can control it by contributing to it and participating in its future development.
By competing you kill it, and you are killing it stone dead, because no one can add a feature without being held back by the users of the other fork(s). > 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. What kind of people are you working with? How rude can people get? This is open source for goodness sake. You aint paying for this stuff, on the contrary, its costing me a fortune. I have a 1977 camper van that I am currently restoring, someone once said to me "anything you do to it, will be an improvement", well that was the state of MC1.0. It's about teamwork, and merging of talents. I never said I was qualified to take on maintenance of MC, I never wanted to do it. The fact is that MC1 is unusable, and someone had to fix it. The future of MC depends entirely upon the contribution of a team of people, but your attitude and the attitude of these myopic individuals precludes it, because none of you will contribute to the team effort required. You have a community full of people who write great code and dont write a single class comment, and yet their often unusable contributions are accepted without being completely insulted! > So we pay attention. > Those people have not contributed to MC either therefore their input is completely mute and irrelevant. I have said many times before, the code is not relevant it is the attitude that is important. If you dont like the code then the repo is open to fix it, and the forums are available to comment on it. Some people have found their feedback incorporated within the hour! People who cant be bothered to offer feedback or participate, have no right to criticise. Ok the tests are not up to scratch, I cant help it if whoever wrote the tests made them incomprehensible. When lukas loaded MC1.5 an installation error didnt completely unload the previous version of MC1 then he complained that there were lots of unsent messages. I don't have time to work on MC1.5 anymore, so those who say "dont use keiths code", are sending a huge message to anyone who cant make a perfect contribution to the community not to bother, your contribution will be discarded. > When I took the time to give feedback on kernel extensions or rio this > But you never even understood what the reason behind kernel-extension was, you criticised it and refused to use anything that depended on it, because it wasn't perfectly what you wanted, and it contained method overrides. That was the whole point, it was supposed to contain method overrides. If you put all of the method overrides for the kernel in one place, then multiple overlapping method overrides from different packages do not occur, there will be no conflicts. Having them in Kernel-Extensions gives you a place to manage them and participate in the discussion over what would be accepted or not. You didn't really participate in that discussion, you simply said things along the line of Kernel-Extensions includes Null therefore we dont like it, full stop. Again you threw the baby out with the bath water. When I stopped using Kernel-Extensions, and started using changesets to publish exactly the same code without method overrides, all of a sudden the same code became magically acceptable! You might be interested to know that more than 80-90% of what was Kernel-Extensions has already been added to pharo, so there wasnt so much wrong with it after all. > Do you think that I'm rude because I reply to you or when I do not > reply? > > Its got nothing to do with replying or not. Its all to do with your team having the expertise to get SystemEditor working with Traits, for the good of all, but instead you spend time and effort forking MC, for the good of yourselves, and in the process trash a lot of time and effort expended for your benefit. Its to do with your team forking SUnit unnecessarily etc etc >> 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, > You saw how we worked with the settings and preference discussion with > alain. > So Alain is external to your team? He had the courtesy of discussing the preferences ideas with the wider community, and for that I thanked him, and added him to my "non-rude" list. > 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. > Hang on... this is a list of projects, most of which dont have any code yet, and you are talking about rejecting stuff that doesnt meet your standards! That's exactly what I mean. If you spec out a project, plan it, and "contribute" to the team that works on it, then it will meet your standards by definition. Therefore there is no need to prejudice anything with such comments as "if 'their' work its not up to 'our' standards". That's my whole point, you get the standards you want by participating in the process, not by looking down your nose at the contributions being hacked by some poor old stressed out full time carer. >> 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 > These "some people", are more folks who have never sent me a single email discussing the design. And by the way Rio has had three complete redesigns since it was first written, incorporating various feedback and ideas. Thankfully I have "some emails" from "some people" who like it Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
