>> > > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
