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.
I agree but it means that other pharoers should stand up and sign for that because I'm full and will probably continue to be.
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.
Ok so this is a good news.
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).
yes this is also an alternative.
we will start by fixing packageInfo
:-) right!
R -
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project