given what I consider to be constraints - and these are not complaints at all, just observation which I am quite happy with 1) 3 harvesters 2) minimal software support for sophisticated branch or release management
I wonder if it would be better to put more effort into expectation management amongst the community. i.e define and document what the update stream represents, and what a 'release' represents. I think it is fantastic we have an update stream. It shows progress, and allows interested folk to test the integration by the harvesters and provide feedback. I do not consider each update to be a 'release' or stable. It is not blessed to me like updates that used to come out of Squeak Central. To me it just shows progress, even if it introduces bugs. A bug can be reported on the list/tracker, feedback can help the next update. each step we move forwards, in a small controlled fashion. Perhaps once a milestone is reached, or some considered point in the future - a release is declared and built. Perhaps people who don't want to be on the development-edge do not update from the update stream until a time that it is recommended. Updates are addictive I find, but I have set my expectations and enjoy the progress. just my thoughts, I would prefer the harvesting and update process is not complicated trying to satisfy too many requirements. From my point of view it is important we can test the integration represented in the update stream, since there should be a way that we can scale the testing amongst a wider group outside the harvesters. It is perhaps interesing, (or not), that I was discussing something similar with Yann the other day. We were talking about MCC and what exactly it was - we did not really know. The next day a post on the Seaside list mentioned the move to universes in that context and constraints. Yann and I were wondering if it would be useful (or not) to have a bit more of the model of Envy maps in Monticello. We did not have any great ideas, just a feeling that Universes, MC, MCC, SM, Squeak SVN etc just demonstrate many forces that pull the needs for configuration management and version control in different directions. I think trying to solve this general problem: updates, branches, releases, backporting, distribution, approval, integration, etc is just very hard. My suggestion with Pharo would not be to do anything particularly clever at the moment as long as everyone knows what is to be expected from the current process. That way we keep moving forward without needing to reinvent too much in one go. cheers, Mike _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
