>> >> I think we should consider cribbing from the model that Linux distros >> use: >> >> Load (more precisely: use -- we might not be able to load it) a / >> specific/ version of the Squeak tool, and then apply a separate >> (Pharo- >> maintained) set of patches to make it Pharo compliant. > > but only the developer of the tool can do that.
No, quite the opposite: The Pharo maintainers maintain the Pharo compliance patches for every tool we import, the tool developer should not be bothered with these -- should not even see them. Only a subset of these patches -- the bugfixes created in the Pharo community -- should be pushed up to the tool developer. This way both worlds could get the best of both worlds: The tool developers still get bugfixes posted despite their original implementation possibly being/becoming incompatible with Pharo. The Pharo community gets the freedom to become incompatible with Squeak without loosing the benefits of ongoing tool development on Squeak. I am not saying this is the only solution, just describing what is a 'field proven' model in the Linux community which seems to perfectly implement the stated goals of Pharo. > >> [...for version management] >>> The vision is bytecode loader >> >> Pleas don't go there. Byte-code loading is a very nice-to-have in >> deployment scenarios (lazy plugin loading, live update delivery to >> deployed apps etc) but if there is one thing that using VW's Store >> has >> taught me it is that it definitely should not be part of a code >> repository that is used for development code version management. > > This is in VW store is bad. I do not see why a package MCZ could not > ship with > a byte-code synchronized version of the source. Then we could have a > stripper > or a synchronizer that recompile the source code and produce new > bytecode. In my experience it 'poisons' the repository with packages that load fine as bytecode but fail to load as source. Mostly in 'auto brain surgery' scenarios where the /source/ should contain more load ordering hints (but never attains that level because the binary version hides these bugs). I reiterate that VW shows that source loading is fast enough -- even for rather large updates. So in my opinion 'fast enough' source loading should be attained first, and bin-loading should be added later as an option (and probably not in the code repository but perhaps in a cache in front of such a repository, or maybe sideways as part of a build process). > > we will start by fixing packageInfo :-) right! R - _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
