[Pharo-project] a process to maintain non core package
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.
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
In PackageInfo/MC1.5 packages keep knowledge of where they were loaded from in order to support this scenario Keith
thanks for the info. Stef On Aug 8, 2009, at 8:20 PM, Keith Hodges wrote:
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
In PackageInfo/MC1.5 packages keep knowledge of where they were loaded from in order to support this scenario
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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). - 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. An automated build process could load packages into new builds and report the result of the tests. 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). 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
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
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
I believe Joseph Pelrine work on one for the "Squeak World Tour" fork. http://desk.org:8080/CampSmalltalk/Squeak%20World%20Tour%20Results From time to time he thinks of bring it up to date, but there is a general lack of interest... However I can ask him for a spec sheet/objectives for the product and see how they match to other proposals. If people are curious about why he would know a bit about package management then consider http://www.amazon.com/Mastering-Envy-Developer-Joseph-Pelrine/dp/0521666503 On 9-Aug-09, at 9:03 AM, Michael Roberts wrote:
do we have a list of candidate package management systems?
cheers,
Mike
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
I have ginsu on my disc since years. Ginsu was a good declarative model (now we have MC which plays the same role). What we are missing is a package management system. So may be metacello can play this role. I think that once we will have cleaner and better modular package we should be able to rely on an external build process to integrate and release pharo. Right now script loader is a big bag of hack and scripts which were mandatory to deal with dependent packages and other dirty things. Also a true atomic loader will help. (I mean true as opposite of Ginsu/MC<1.5 loader which could not deal with the issue of modifying parts of the system used to load the system). So all in all I do not think that there is a need for Ginsu right now. Cleaning and making MC better (probably MC2) is the way to go. Something I feel that MC1.0 was designed from a UI point of view and is a bit arcane to script. Stef On Aug 9, 2009, at 7:41 PM, John M McIntosh wrote:
I believe Joseph Pelrine work on one for the "Squeak World Tour" fork. http://desk.org:8080/CampSmalltalk/Squeak%20World%20Tour%20Results
From time to time he thinks of bring it up to date, but there is a general lack of interest... However I can ask him for a spec sheet/objectives for the product and see how they match to other proposals.
If people are curious about why he would know a bit about package management then consider http://www.amazon.com/Mastering-Envy-Developer-Joseph-Pelrine/dp/0521666503
On 9-Aug-09, at 9:03 AM, Michael Roberts wrote:
do we have a list of candidate package management systems?
cheers,
Mike
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
I have ginsu on my disc since years. Ginsu was a good declarative model (now we have MC which plays the same role). What we are missing is a package management system. So may be metacello can play this role. I think that once we will have cleaner and better modular package we should be able to rely on an external build process to integrate and release pharo. Right now script loader is a big bag of hack and scripts which were mandatory to deal with dependent packages and other dirty things. Also a true atomic loader will help. (I mean true as opposite of Ginsu/MC<1.5 loader which could not deal with the issue of modifying parts of the system used to load the system). So all in all I do not think that there is a need for Ginsu right now. Cleaning and making MC better (probably MC2) is the way to go. Something I feel that MC1.0 was designed from a UI point of view and is a bit arcane to script. Stef
MC1.6 is the one with atomic loading Keith
El dom, 09-08-2009 a las 14:26 +0200, Adrian Lienhard escribió:
- 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
Yes, something like the Debian process, but simplified for pharo. Also it is important to have a way to track unmantained packages to avoid the squeak map problem.
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).
- 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.
An automated build process could load packages into new builds and report the result of the tests.
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).
Cheers, Adrian
Half of what you describe is in Sake/Packages Keith
Keith Hodges wrote:
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" Same goal as for Sake/Packages, and it works for me.
(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).
- There should be a responsible maintainer for each package
Not a realistic proposition. Better to be open to all to maintain on behalf of the community.
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore shows you what is loaded, and this should be merged into PackageOrganization. Keith
Keith you mentioned that you did videos about Bob or sake. Do you have them so that I can watch them? Stef On Aug 9, 2009, at 10:01 PM, Keith Hodges wrote:
Keith Hodges wrote:
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" Same goal as for Sake/Packages, and it works for me.
(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).
- There should be a responsible maintainer for each package
Not a realistic proposition. Better to be open to all to maintain on behalf of the community.
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore
shows you what is loaded, and this should be merged into PackageOrganization.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribió:
Keith Hodges wrote:
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" Same goal as for Sake/Packages, and it works for me.
(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).
- There should be a responsible maintainer for each package
Not a realistic proposition. Better to be open to all to maintain on behalf of the community.
Why not, the debian project use this model since 1996 or something like that. The same package system the use report packages not maintained anymore (orphans and waiting for mantainer)
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore
shows you what is loaded, and this should be merged into PackageOrganization.
Keith
Keith, it really appear that you have built the platform to bring this dream a reality, but somehow (the details are not relevant now) you haven't materialized a "steve jobs" kind of show off of it. I believe your words, based on your other projects that I use. What do you need, as Stephan said, to bring a complete, working, and as simple to understand for all of us of your tools. This is my proposal: I think that if you can put a working example (minimal, a couple of packages, and the core) using Pharo, the pharo community happily will support you. No more fights, no more angry mails, just the working full simple demo. I offer to you access to a server with a homologated IP to install (I can help you here too) to setup the repositories to test your tools. If the community agree to use your tools and process I can also buy and donate the domain to host this infrastructure. In the beginning I will host it, if someday it grows more than I can support (bandwidth mainly, the space isn't problem) then we will discuss with the community to migrate the repos to a bigger servers or to ask for donations or some other party that can host it (maybe the folks of seasidehosting). We'll see in that moment. But, Keith, we need to see to believe and support you. Indeed, Pharo needs a real proccess to not get to the same point that squeak. Cheers, Miguel Cobá
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Miguel Enrique Cobá Martinez wrote:
El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribió:
Keith Hodges wrote:
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"
Same goal as for Sake/Packages, and it works for me.
(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).
- There should be a responsible maintainer for each package
Not a realistic proposition. Better to be open to all to maintain on behalf of the community.
Why not, the debian project use this model since 1996 or something like that. The same package system the use report packages not maintained anymore (orphans and waiting for mantainer)
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore
shows you what is loaded, and this should be merged into PackageOrganization.
Keith
Keith, it really appear that you have built the platform to bring this dream a reality, but somehow (the details are not relevant now) you haven't materialized a "steve jobs" kind of show off of it. I believe your words, based on your other projects that I use. What do you need, as Stephan said, to bring a complete, working, and as simple to understand for all of us of your tools. This is my proposal:
I think that if you can put a working example (minimal, a couple of packages, and the core) using Pharo, the pharo community happily will support you. No more fights, no more angry mails, just the working full simple demo. I offer to you access to a server with a homologated IP to install (I can help you here too) to setup the repositories to test your tools. If the community agree to use your tools and process I can also buy and donate the domain to host this infrastructure. In the beginning I will host it, if someday it grows more than I can support (bandwidth mainly, the space isn't problem) then we will discuss with the community to migrate the repos to a bigger servers or to ask for donations or some other party that can host it (maybe the folks of seasidehosting). We'll see in that moment.
But, Keith, we need to see to believe and support you.
I've seen Keiths Seaside gui he made for Bob though I don't know if he wants it to be shown around. It looks nice. Here's a quick explanation for those not familiar with them. Sake is essentially Make for Smalltalk, allowing you to define tasks that can depend on other tasks. Bob is a build tool, which handles all the actual building using Sake tasks to define what to do. With Bob+Sake, you can define a build to: 1. Start with a defined image. 2. Load a set of packages into that image (either specific versions or the latest ones). 3. Apply specific fixes from the bug tracker. 4. Run tests. 5. Save the new image and export all the new package versions to a new folder. You can define tasks to apply features to an image such as closures or perform updates between versions or even update applications. For example, you can define tasks to do the following sort of things Pharo1.0beta -> Pharo1.0final Pharo1.0beta -> Pharo-latest. Squeak 3.10.2 image -> 3.10.2+closures. Squeak 3.8 image -> 3.8+closures. Seaside 2.8 -> 2.9. Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite packages. Once defined, these will allow anyone to repeatably and reliably produce an updated image+packages without changing the original image. You can then do things like upgrade a production image based on 1.0beta to 1.0final just by using the same task but telling it to start with your production image instead of the 1.0beta distribution image. Since it produces a new image you don't risk clobbering your original. You should also be able to replace the update stream with distributing build definitions for Bob. I believe one of the key points to this setup is that you don't need to work on the image as a single blob any more, you only work on the packages and use Bob to handle the messy image building stuff. That does depend on the image being sectioned into packages of course. If I've had any misunderstandings here I hope Keith will correct me but the system looks awesome :)
Thanks. I tried to follow sake/package and bob and I got lost. Now for the update there are some tricky operations from time to time (and yes ideally I would like to use a system like the one you describe).
Why not, the debian project use this model since 1996 or something like that. The same package system the use report packages not maintained anymore (orphans and waiting for mantainer)
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore
shows you what is loaded, and this should be merged into PackageOrganization.
Keith
Keith, it really appear that you have built the platform to bring this dream a reality, but somehow (the details are not relevant now) you haven't materialized a "steve jobs" kind of show off of it. I believe your words, based on your other projects that I use. What do you need, as Stephan said, to bring a complete, working, and as simple to understand for all of us of your tools. This is my proposal:
I think that if you can put a working example (minimal, a couple of packages, and the core) using Pharo, the pharo community happily will support you. No more fights, no more angry mails, just the working full simple demo. I offer to you access to a server with a homologated IP to install (I can help you here too) to setup the repositories to test your tools. If the community agree to use your tools and process I can also buy and donate the domain to host this infrastructure. In the beginning I will host it, if someday it grows more than I can support (bandwidth mainly, the space isn't problem) then we will discuss with the community to migrate the repos to a bigger servers or to ask for donations or some other party that can host it (maybe the folks of seasidehosting). We'll see in that moment.
But, Keith, we need to see to believe and support you.
I've seen Keiths Seaside gui he made for Bob though I don't know if he wants it to be shown around. It looks nice.
Here's a quick explanation for those not familiar with them. Sake is essentially Make for Smalltalk, allowing you to define tasks that can depend on other tasks. Bob is a build tool, which handles all the actual building using Sake tasks to define what to do.
With Bob+Sake, you can define a build to: 1. Start with a defined image. 2. Load a set of packages into that image (either specific versions or the latest ones). 3. Apply specific fixes from the bug tracker. 4. Run tests. 5. Save the new image and export all the new package versions to a new folder.
You can define tasks to apply features to an image such as closures or perform updates between versions or even update applications.
For example, you can define tasks to do the following sort of things Pharo1.0beta -> Pharo1.0final Pharo1.0beta -> Pharo-latest. Squeak 3.10.2 image -> 3.10.2+closures. Squeak 3.8 image -> 3.8+closures. Seaside 2.8 -> 2.9. Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite packages.
Once defined, these will allow anyone to repeatably and reliably produce an updated image+packages without changing the original image. You can then do things like upgrade a production image based on 1.0beta to 1.0final just by using the same task but telling it to start with your production image instead of the 1.0beta distribution image. Since it produces a new image you don't risk clobbering your original.
You should also be able to replace the update stream with distributing build definitions for Bob.
I believe one of the key points to this setup is that you don't need to work on the image as a single blob any more, you only work on the packages and use Bob to handle the messy image building stuff. That does depend on the image being sectioned into packages of course.
If I've had any misunderstandings here I hope Keith will correct me but the system looks awesome :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This sounds great. Can you fill in some links on the wiki? Thanks mike On Monday, August 10, 2009, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
Miguel Enrique Cobá Martinez wrote:
El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribió:
Keith Hodges wrote:
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"
Same goal as for Sake/Packages, and it works for me.
 (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).
- There should be a responsible maintainer for each package
Not a realistic proposition. Better to be open to all to maintain on behalf of the community.
Why not, the debian project use this model since 1996 or something like that. The same package system the use report packages not maintained anymore (orphans and waiting for mantainer)
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore
shows you what is loaded, and this should be merged into PackageOrganization.
Keith
Keith, it really appear that you have built the platform to bring this dream a reality, but somehow (the details are not relevant now) you haven't materialized a "steve jobs" kind of show off of it. I believe your words, based on your other projects that I use. What do you need, as Stephan said, to bring a complete, working, and as simple to understand for all of us of your tools. This is my proposal:
I think that if you can put a working example (minimal, a couple of packages, and the core) using Pharo, the pharo community happily will support you. No more fights, no more angry mails, just the working full simple demo. I offer to you access to a server with a homologated IP to install (I can help you here too) to setup the repositories to test your tools. If the community agree to use your tools and process I can also buy and donate the domain to host this infrastructure. In the beginning I will host it, if someday it grows more than I can support (bandwidth mainly, the space isn't problem) then we will discuss with the community to migrate the repos to a bigger servers or to ask for donations or some other I've seen Keiths Seaside gui he made for Bob though I don't know if he wants it to be shown around. It looks nice.
Here's a quick explanation for those not familiar with them. Sake is essentially Make for Smalltalk, allowing you to define tasks that can depend on other tasks. Bob is a build tool, which handles all the actual building using Sake tasks to define what to do.
With Bob+Sake, you can define a build to: 1. Start with a defined image. 2. Load a set of packages into that image (either specific versions or the latest ones). 3. Apply specific fixes from the bug tracker. 4. Run tests. 5. Save the new image and export all the new package versions to a new folder.
You can define tasks to apply features to an image such as closures or perform updates between versions or even update applications.
For example, you can define tasks to do the following sort of things Pharo1.0beta -> Pharo1.0final Pharo1.0beta -> Pharo-latest. Squeak 3.10.2 image -> 3.10.2+closures. Squeak 3.8 image -> 3.8+closures. Seaside 2.8 -> 2.9. Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite packages.
Once defined, these will allow anyone to repeatably and reliably produce an updated image+packages without changing the original image. You can then do things like upgrade a production image based on 1.0beta to 1.0final just by using the same task but telling it to start with your production image instead of the 1.0beta distribution image. Since it produces a new image you don't risk clobbering your original.
You should also be able to replace the update stream with distributing build definitions for Bob.
I believe one of the key points to this setup is that you don't need to work on the image as a single blob any more, you only work on the packages and use Bob to handle the messy image building stuff. That does depend on the image being sectioned into packages of course.
If I've had any misunderstandings here I hope Keith will correct me but the system looks awesome :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Unfortunately, Bob is not open source: On Aug 10, 2009, at 2:07 PM, Keith Hodges wrote:
p.p.s. Bob is not going to be released as open source, if you would like the ability to build your images daily, and run the test suites against your deliverables, then please do email me for licensing terms.
Of course, the community could still choose to use it for managing the release process, but that seems unlikely. - Brian On Aug 10, 2009, at 1:54 PM, Douglas Brebner wrote:
Miguel Enrique Cobá Martinez wrote:
El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribió:
Keith Hodges wrote:
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"
Same goal as for Sake/Packages, and it works for me.
(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).
- There should be a responsible maintainer for each package
Not a realistic proposition. Better to be open to all to maintain on behalf of the community.
Why not, the debian project use this model since 1996 or something like that. The same package system the use report packages not maintained anymore (orphans and waiting for mantainer)
- For each package there should be a known way to discuss and report problems
That's just arbitrary metadata in the package definition, for more general topics we use the packages@squeakfoundation.org mailing list
- A gate keeper includes and removes packages from the set depending on their status
Probably too complicated to be practical.
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
Sake/Packages supports a stable and a beta release of each package.
packages would first go to the unstable set and then move up to the stable set after a while.
An automated build process could load packages into new builds and report the result of the tests.
Bob does that.
The package management system does not need to be very sophisticated,
Sake is as simple as possible for defining actions with dependencies.
but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded).
Sake/Packages uses the class browser as is, no extra GUI is required.
Packages provided explore
shows you what is loaded, and this should be merged into PackageOrganization.
Keith
Keith, it really appear that you have built the platform to bring this dream a reality, but somehow (the details are not relevant now) you haven't materialized a "steve jobs" kind of show off of it. I believe your words, based on your other projects that I use. What do you need, as Stephan said, to bring a complete, working, and as simple to understand for all of us of your tools. This is my proposal:
I think that if you can put a working example (minimal, a couple of packages, and the core) using Pharo, the pharo community happily will support you. No more fights, no more angry mails, just the working full simple demo. I offer to you access to a server with a homologated IP to install (I can help you here too) to setup the repositories to test your tools. If the community agree to use your tools and process I can also buy and donate the domain to host this infrastructure. In the beginning I will host it, if someday it grows more than I can support (bandwidth mainly, the space isn't problem) then we will discuss with the community to migrate the repos to a bigger servers or to ask for donations or some other party that can host it (maybe the folks of seasidehosting). We'll see in that moment.
But, Keith, we need to see to believe and support you.
I've seen Keiths Seaside gui he made for Bob though I don't know if he wants it to be shown around. It looks nice.
Here's a quick explanation for those not familiar with them. Sake is essentially Make for Smalltalk, allowing you to define tasks that can depend on other tasks. Bob is a build tool, which handles all the actual building using Sake tasks to define what to do.
With Bob+Sake, you can define a build to: 1. Start with a defined image. 2. Load a set of packages into that image (either specific versions or the latest ones). 3. Apply specific fixes from the bug tracker. 4. Run tests. 5. Save the new image and export all the new package versions to a new folder.
You can define tasks to apply features to an image such as closures or perform updates between versions or even update applications.
For example, you can define tasks to do the following sort of things Pharo1.0beta -> Pharo1.0final Pharo1.0beta -> Pharo-latest. Squeak 3.10.2 image -> 3.10.2+closures. Squeak 3.8 image -> 3.8+closures. Seaside 2.8 -> 2.9. Pharo-latest -> Pharo-latest + Seaside-latest + your own favourite packages.
Once defined, these will allow anyone to repeatably and reliably produce an updated image+packages without changing the original image. You can then do things like upgrade a production image based on 1.0beta to 1.0final just by using the same task but telling it to start with your production image instead of the 1.0beta distribution image. Since it produces a new image you don't risk clobbering your original.
You should also be able to replace the update stream with distributing build definitions for Bob.
I believe one of the key points to this setup is that you don't need to work on the image as a single blob any more, you only work on the packages and use Bob to handle the messy image building stuff. That does depend on the image being sectioned into packages of course.
If I've had any misunderstandings here I hope Keith will correct me but the system looks awesome :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Lienhard -
Brian Brown -
Douglas Brebner -
John M McIntosh -
Keith Hodges -
Michael Roberts -
Miguel Enrique Cobá Martinez -
Stéphane Ducasse