On 5/17/07, Keith Hodges <[EMAIL PROTECTED]> wrote:
I think that the majority of the problems that previous teams had can be resolved by improving the tools.
We need better tools. I agree completely. Better tools will not make all problems go away, though. In fact, I do not think they will make the biggest problems go away. I think the biggest problem is that the quality of code in Squeak is not nearly high enough. It is too buggy, the code is too ugly, and it is a big ball of mud. The process you describe works in an XP project, where everybody who is committing is in the same room, or at least is in constant communication with everybody else. It won't work is a highly distributed project. Open source projects always have a small set of "committers", and that is basically what the release team is.
My suggestions would be to plan a number of items and see them all worked on together. Integrating all of the tasks simultaneously and regularly. This is effectively what I have done on 3.9.1
It is easy for one person to integrate. It is hard for an open source group to plan. I don't think your diagrams are accurate. Edgar is just taking changes that other people have made and putting them in a single image, converting them into MC format. This is hard enough. He doesn't fix bugs, refactor code, etc. Well, sometimes he does, but that is not what he is doing as an officlal member of the release team. We keep the list of proposed changes public. Anybody can file them into their image to try them out in advance of an official release.
This was not viable before, because such a build script would constantly run into problems. For example, rather than tweak the TTFFont Speedup fix to make it loadable, I spent a couple of days fixing the loader so the problem should not reoccur. Removing loading order dependencies should also make this simultaneous-integration approach one step closer to reality.
I think that change to TTFFont broke something. I get font errors nearly every time I try to test a package. I'm hoping that once I figure out the problem, it will be easy to fix. But we might need to back out that change, or some other change to fonts. This is why integration is difficult. The tools are only part of the problem.
I demonstrated this 4 months ago, and Installer supports the ability to have stable/unstable/personal versions of each script, via its search 'path' parameter.
i tried it out and it didn't work for me. Does it work now? How can I tell? Keith, be very conservaitve about the changes you make to MC. You will find that getting people to use your version is nontrivial, and the more changes you make, the harder it will be to get people to use it. There are already too many versions of MC. Integrating those changes is valuable, making a new version that is incompatible with all the others is not valuable. -Ralph _______________________________________________ V3dot10 mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
