a process to maintain non core package

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