Keith, when Ralph signed on for 3.10, we discussed options for how to manage updates and a migration towards packages given the existing tools, including the updates system, Monticello, and Package Universes. I am happy to help make the PU part work as well as I can, but I need to really understand how it fits into the overall plan, both for 3.10 and for the packagizing agenda in general. If I am simply told why doesn't it do X, it sounds to me like asking why blowing on a violin is unrewarding.
Let me sketch my understanding of a good 3.10 process as I understand it. By all means let's discuss how to improve on it. First, not all code is in packages. For such code, you have no other choice but fileouts. To manage such fileouts, the update stream seems just fine. It is, after all, the solution used by the original Squeak team. Second, some code is already in packages. For such code, you should update the packages directly. People can then get the newest version of them by doing "upgrade all" in a package universes browser. Finally, there is the issue of code that gets moved to a package during the course of 3.10's development. I agree this is trickier, and there are a few approaches that can be done. How about I stop here, and ask for which packages this has happened so far? For these trickier cases it would help to know about the actual cases that are being faced. Given the above, I do not understand the new features you suggest. Specifically: "download from: (Installer mantis bugFix: 474)" I do not see any advantage of this compared to explicitly posting the fix through one of the two ways I described above. Either add it to the update stream, or post a new version of the relevant package. "Into my universe should the need arise for a package to depend upon a fix, which they frequently do." If this is happening, then can you not simply tell people to run updates before upgrading packages? "Secondly I can publish a package together with the "user interaction automation" e.g. download from: (Installer ss project:'Seaside'; answer: '*config*' with:'admin'; install: 'Seaside2.8a1-kph.mcz')." Yes, but assuming that Seaside's authors are really so hard to work with, you can post a customized version of the package that is properly configured. This is not only possible, but IMHO the standard way of dealing with a package that needs customizing for your particular distribution of Squeak. I did this kind of thing several times when putting together the 3.7 stable universe. -Lex _______________________________________________ V3dot10 mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
