2009/3/21 Keith Hodges <keith_hodges@yahoo.co.uk>:
Janko Mivšek wrote:
Guys,
Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No!
I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best.
So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work!
Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted!
Best regards Janko
Again its not about the technical choice, its about the philosophical principle. Let me make this clear.
"I spent a year of my time on tools and ideas that may benefit all, only only only only only only only if all choose in principle to use those ideas." (we sort out the technical details in the end).
Check through my last email, and look at what it means to the community if Pharo doesnt adopt MC1.5 and SUnit improved ideas (notice I said ideas, its not just limited to code).
1. You/I will have to manage a separate project JUST for pharo. The new(1 year old) PackageInfo-Base would allow you to export. MyPackage.pharo from your main distribution.
2. You will have to manage a separate test suite JUST for Pharo. The SUnit-improved is designed to allow tests to be marked and categorised as to what should work where. This scheme should also apply to other testing frameworks as they are integrated (SSpec).
3. You will have to manage a separate load script/universe for your pharo code, and users will not have a place to tweak their load scripts for pharo. Thus to support pharo you are forced to actually try loading your code in pharo regularly. Remember pharo is a moving target, so you will have to test it every month/week or so. IF your code ever fails to load you will get a black mark of incompetence from the community, so you had better keep on top of it. Meanwhile the squeak users can upload their feedback of what is needed to make your package work in squeak into the load scripts in Sake/Packages. Then on your next iteration you can go and pick up the required changes, at your leisure.
If you wonder why I keep banging on about this, I have over 40 packages that I maintain both publically and as part of my work. I have gone to an extreme amount of effort to try and minimise the pain, and the pharo guys are ignoring the IDEAS and the code, and therefore making unnecessary work for everyone.
Keithy, what you proposing is change the development process pattern which people used to do for a years now, to a new, not yet clearly evaluated paradigms. I think you should be aware that forcing people to change their development style will meet a certain oppression. From your side, as an evangelist of a new approach, it very important to show how easy & painless the new process is going comparing to old one. Write tutorials , show simple 1.2.3. steps etc etc. Blaming the people that they keep using old development techniques is not the way to go. I think that Stephane clearly understands a different problems of software development , packaging, maintaining & distributing. What he maybe not clearly sees is a big win from using approach proposed by you. I hope you will find a meeting points to make interchange between Squeak & Pharo (and other forks) be painless, fun and productive.
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.