do we have a list of candidate package management systems? cheers, Mike On Sun, Aug 9, 2009 at 1:52 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> wrote:
On Aug 9, 2009, at 2:26 PM, Adrian Lienhard wrote:
Hi,
I really think we need a package management system and a process to maintain it.
The goal is that loading and using non-core packages "just works" (unlike for instance SqueakMap, where loading more often fails than succeeds because there are a lot of obsolete packages and a dependency mechanism is missing).
Yeap!
- There should be a responsible maintainer for each package - For each package there should be a known way to discuss and report problems - A gate keeper includes and removes packages from the set depending on their status
This limits the set of included packages (at least initially) but would increase the quality and hence the user experience.
Maybe there could be two sets, a stable and an unstable set. New packages would first go to the unstable set and then move up to the stable set after a while.
Yes but if we take for example sound. When I integrate a fix from Cuis I do not want to get
An automated build process could load packages into new builds and report the result of the tests.
Yes!
The package management system does not need to be very sophisticated, but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Yes. We should start incrementally fixing that. I should look at Metacello and MC1.5 when I get more time.
Stef
Cheers, Adrian
On Aug 8, 2009, at 12:31 , Stéphane Ducasse wrote:
Hi
in the future I would like to have a process like that to maintain package like sound (or morphic extras) or any package that are not core else we will not be able to maintain them or to apply package wide changes.
- we mark the packages that are not in the image but that we want to maintain - at integration step we    load all the external packages - integrate - publish in different repos
Else I bet that we will not be able to maintain the non core packages.
Stef
PS: I'm integrating
Issue 1051: Cuis 0053-ensure-close.1.cs and some changes touched sound so this is good experiment.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project