Reinout Heeck wrote: >> Pharo continues with a not invented here policy, and has made no >> attempt >> to review the code based for projects that could be mutually >> maintained. >> > > I think it is a misanalysis to label that NIH, there are quite > different factors contributing to the lack of pushing contributions > upstream. > > Fail to plan, plan to fail? > As it happens your timing is unfortunate in that a discussion was just > kindled here on which processes and mechanisms to put in place to > solve this issue. > Unfortunately a lot of messages have been posted here to the effect of > making statements without proposing solutions, washing out the > original constructive thread. > It is the fact that proposed solutions have been ignored that brings me to raise these issues. I am not just meaning technical solutions, I primarily mean philosophical and process solutions.
I started working on the technical solutions for this very problem 3 years ago with Stephanes encouragement. Finally I am glad that someone is considering looking at it. >> This is not a fighting attitude, its a pragmatic attitude aiming to >> help >> people to avoid wasting their time and effort. >> > > It would help if the balance of the message traffic moved from > pointing out problems towards discussing solutions > I have been discussing solutions all along. Monticello is our bread and butter for exchanging code, we all want it to be better, we all want it to work everywhere. So it is a strategic choice to chose to adopt and contribute to one implementation of Monticello that is being actively maintained (was - since pharo isnt using it I have stopped maintaining it). SUnit is our bread and butter for testing code, we all want it to work, we all want our tests to be compatible accross forks, we all want as many green tests as possible with as few false negatives as possible. Some of us would like to branch out to use SSpec for testing/design purposes. Many of us would like to have an automated test server, with periodic offline testing. www.squeaksource.com/Testing was established to address these very same issues. We want a minimal image, that we can pull things out of and reliably put things back into no matter what image we are using even if it doesnt yet have a GUI. In a multifork world we need to capture the knowledge of what works where, and what patches are needed to make things work where. Sake/Packages was developed for this purpose. I look forward to good things from your discussions. etc etc etc Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
