[Pharo-project] Fwd: [Seaside-dev] preliminary Seaside 2.9 alpha universe
The new and easy way to load Seaside takes up to 10 steps (see below). We should try to make this even less painful in Pharo. I assume, having Universes pre-loaded will already reduce half of the steps, but how can it be further simplified? Adrian Begin forwarded message:
From: "Philippe Marschall" <philippe.marschall@gmail.com> Date: September 24, 2008 10:21:16 PM GMT+02:00 To: "Seaside - developer list" <seaside- dev@lists.squeakfoundation.org> Subject: [Seaside-dev] preliminary Seaside 2.9 alpha universe Reply-To: Seaside - developer list <seaside-dev@lists.squeakfoundation.org
Hi
Seaside 2.9 was always hard to load. We always said that we would fix this and this is a preview of what we expect the solution to look like.
After some evaluation of what is available in Squeak we had only two options, either start from scratch or use universes [1]. We decided to give universes a shot. Universes is something like a debian distribution universe for squeak.
So how do you load this stuff: 1. get Universes, if you don't already have it (3.10) 1.1 get an XML parser [2] 1.2 get universes [3] 1.3 optionally the the OB universe browser [4] 2. save the *.packages to your image directory 3. load the attached .mcz 4. evaluate UUniverse switchSystemToUniverse: UUniverse seasideAndServers 5. in the world menu open a "Universe Browser" either basic or enhanced 6. "update list from network" 7. choose a distribution 8. choose a server
There are still some unsolved issues like the naming of alpha an beta versions. We probably want website integration as well. One possible change would be to move the tests to a separate tests category.
[1] http://wiki.squeak.org/squeak/3785 [2] http://www.squeaksource.com/universes.html [3] http://www.squeaksource.com/XMLSupport.html [4] http://www.squeaksource.com/OBUniverse.html
Cheers Philippe
_______________________________________________ seaside-dev mailing list seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
why can we have an installer script or mcm ? We should be able to have one click install too. Stef On Sep 24, 2008, at 10:55 PM, Adrian Lienhard wrote:
The new and easy way to load Seaside takes up to 10 steps (see below). We should try to make this even less painful in Pharo. I assume, having Universes pre-loaded will already reduce half of the steps, but how can it be further simplified?
Adrian
Begin forwarded message:
From: "Philippe Marschall" <philippe.marschall@gmail.com> Date: September 24, 2008 10:21:16 PM GMT+02:00 To: "Seaside - developer list" <seaside-dev@lists.squeakfoundation.org
Subject: [Seaside-dev] preliminary Seaside 2.9 alpha universe Reply-To: Seaside - developer list <seaside-dev@lists.squeakfoundation.org
Hi
Seaside 2.9 was always hard to load. We always said that we would fix this and this is a preview of what we expect the solution to look like.
After some evaluation of what is available in Squeak we had only two options, either start from scratch or use universes [1]. We decided to give universes a shot. Universes is something like a debian distribution universe for squeak.
So how do you load this stuff: 1. get Universes, if you don't already have it (3.10) 1.1 get an XML parser [2] 1.2 get universes [3] 1.3 optionally the the OB universe browser [4] 2. save the *.packages to your image directory 3. load the attached .mcz 4. evaluate UUniverse switchSystemToUniverse: UUniverse seasideAndServers 5. in the world menu open a "Universe Browser" either basic or enhanced 6. "update list from network" 7. choose a distribution 8. choose a server
There are still some unsolved issues like the naming of alpha an beta versions. We probably want website integration as well. One possible change would be to move the tests to a separate tests category.
[1] http://wiki.squeak.org/squeak/3785 [2] http://www.squeaksource.com/universes.html [3] http://www.squeaksource.com/XMLSupport.html [4] http://www.squeaksource.com/OBUniverse.html
Cheers Philippe <Seaside-Universe-pmm.18.mcz><seaside.packages><servers.packages>
_______________________________________________ seaside-dev mailing list seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 9/25/08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
why can we have an installer script or mcm ? We should be able to have one click install too.
It will eventually become simpler. An installer script or an mcm is not an option because that would always load one fixed configuration. Only with Universe we have the possibility to load the set of packages the developer needs, and pull in a minimal set of required dependencies automatically. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Sep 25, 2008, at 3:51 PM, Lukas Renggli wrote:
On 9/25/08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
why can we have an installer script or mcm ? We should be able to have one click install too.
It will eventually become simpler.
An installer script or an mcm is not an option because that would always load one fixed configuration.
but this is not what we want when we do not use a universe.
Only with Universe we have the possibility to load the set of packages the developer needs, and pull in a minimal set of required dependencies automatically.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, 2008-09-25 at 15:51 +0200, Lukas Renggli wrote:
On 9/25/08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
why can we have an installer script or mcm ? We should be able to have one click install too.
It will eventually become simpler.
An installer script or an mcm is not an option because that would always load one fixed configuration. Only with Universe we have the possibility to load the set of packages the developer needs, and pull in a minimal set of required dependencies automatically.
What will you do with current channels (beta,...) with seaside. Are you preparing an universe for each. The most important thing that is lacking in Universe is to assign a package version to a certain channel. This leads to something I've seen some times: A package the is called Seaside-beta-anything which is broken as soon as this beta becomes stable. For me universes capture the basic idea of an package distribution tree but it lacks essential stuff. Without that I don't know if it is worth it. Having a maintained universe only for seaside is a good thing. But you have to include KomHttpServer as well which will also be in the "official" universe. And AFAIK you can't merge universes, right? We could convert your universe into a Monticello configuration. It may sound stupid as first but I don't think it is hard to do and we wouldn't need to have universes and XML parser in the image. my 2 cents, Norbert
but this is not what we want when we do not use a universe.
To be able to properly load Seaside a system that can handle dependencies is a requirement. To our knowledge, Universe is the only system in Squeak/Pharo that can handle this task. If you do not like Universes you can always load the Monticello packages manually following this graph: <http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png>. Good luck ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
An installer script or an mcm is not an option because that would always load one fixed configuration.
But this is not what you want when you do not use a Universe?
but this is not what we want when we do not use a universe.
To be able to properly load Seaside a system that can handle dependencies is a requirement.
so I'm confused I thought that exactly mcm allow to specify exact version.
To our knowledge, Universe is the only system in Squeak/Pharo that can handle this task.
If you do not like Universes you can always load the Monticello packages manually following this graph: <http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png>. Good luck ;-)
But Universe do not have the granularity for following all the small changes. I thought that for the people developing seaside daily you wanted either the latest or been able to go back to exactly one version of a set of components and there the exact version number is a must I do not see the numbering in dependency in Universe. For me Universe is good when a complex program is ok for public consumption not incremental daily changes. So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component** Stef
For me Universe is good when a complex program is ok for public consumption not incremental daily changes.
Do have a look at Sake/Packages equivalent to universes. You can define a package with non-specific versions, i.e. to load the latest seaside when keeping up with the bleeding edge. Packages beta load: 'Seaside'. Or you can define a specific definition based upon specific versions. Packages current load: 'Seaside'. Keith
So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component**
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
An installer script or an mcm is not an option because that would always load one fixed configuration.
But this is not what you want when you do not use a Universe?
Not not? I am confused ;-)
but this is not what we want when we do not use a universe.
To be able to properly load Seaside a system that can handle dependencies is a requirement.
so I'm confused I thought that exactly mcm allow to specify exact version.
mcm is a fixed, ordered set of exact package versions. If we wanted to provide mcm files, we needed to create one for every combination of swazoo/kom (2), tests yes/no (2), development tools yes/no (2), scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... Imagine, if we wanted to add Magritte and Pier to that. We would soon end up with an infinite number of possible combinations, each encoded in a different mcm file.
But Universe do not have the granularity for following all the small changes. I thought that for the people developing seaside daily you wanted either the latest or been able to go back to exactly one version of a set of components and there the exact version number is a must I do not see the numbering in dependency in Universe.
Exactly, but Seaside users usually don't follow small changes. We expect developers to know about the dependencies and be able to load the packages manually. Furthermore, as soon as a version of the packages is loaded, doing small updates through Monticello is usually no big deal. There will be a universe for every release (including alpha and beta releases). Seaside users have the possibility to update from one release to the next.
So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component**
We tried to use mcm in the beginning. Unfortunately not even the developers want a fixed set of packages, but have different focuses and therefore different packages loaded. For example, I focus on JavaScript, while Philippe on different encodings and server adapters, ... So in Universe each package has a list of dependencies to other fixed versions of packages (not strictly, but we use it like this). This allows users to select the parts of Seaside they need (for example kom server, no tests, development tools, scriptaculous support and pier). And boom, Universe automatically builds an ordered list of package versions to load. In this example the list would include the correct versions of Magritte-Core and Magritte-Seaside, even if this was never explicitly declared. Universes is easier for us, because we don't need to prepare all the possible configurations a user wants. Users just select themselves what they want and the system calculates the prerequisites. Now with MC2, the story is again completely different ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Ok I understand now and I agree.
An installer script or an mcm is not an option because that would always load one fixed configuration.
But this is not what you want when you do not use a Universe?
Not not? I am confused ;-)
but this is not what we want when we do not use a universe.
To be able to properly load Seaside a system that can handle dependencies is a requirement.
so I'm confused I thought that exactly mcm allow to specify exact version.
mcm is a fixed, ordered set of exact package versions. If we wanted to provide mcm files, we needed to create one for every combination of swazoo/kom (2), tests yes/no (2), development tools yes/no (2), scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... Imagine, if we wanted to add Magritte and Pier to that. We would soon end up with an infinite number of possible combinations, each encoded in a different mcm file.
But Universe do not have the granularity for following all the small changes. I thought that for the people developing seaside daily you wanted either the latest or been able to go back to exactly one version of a set of components and there the exact version number is a must I do not see the numbering in dependency in Universe.
Exactly, but Seaside users usually don't follow small changes. We expect developers to know about the dependencies and be able to load the packages manually. Furthermore, as soon as a version of the packages is loaded, doing small updates through Monticello is usually no big deal.
There will be a universe for every release (including alpha and beta releases). Seaside users have the possibility to update from one release to the next.
So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component**
We tried to use mcm in the beginning. Unfortunately not even the developers want a fixed set of packages, but have different focuses and therefore different packages loaded. For example, I focus on JavaScript, while Philippe on different encodings and server adapters, ...
So in Universe each package has a list of dependencies to other fixed versions of packages (not strictly, but we use it like this). This allows users to select the parts of Seaside they need (for example kom server, no tests, development tools, scriptaculous support and pier). And boom, Universe automatically builds an ordered list of package versions to load. In this example the list would include the correct versions of Magritte-Core and Magritte-Seaside, even if this was never explicitly declared.
Universes is easier for us, because we don't need to prepare all the possible configurations a user wants. Users just select themselves what they want and the system calculates the prerequisites.
Now with MC2, the story is again completely different ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
Do have a look at Sake/Packages equivalent to universes.
I agree with Keith. Sake/Packages have all the features of universes without a GUI but provide an easy way to define your own universe as you did with Seaside and as you want to do with Pharo (just need to create a new subclass IIUC). I don't understand why people don't want to look at this solution (it's not about you Seaside developers, it's about the whole community. Some told me they would stop using my dev-images if I use Sake/Packages without giving any good reason). I hope Keith won't give up. Bye -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Fri, 26 Sep 2008 08:10:53 +0200 "Damien Cassou" <damien.cassou@gmail.com> wrote:
On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
Do have a look at Sake/Packages equivalent to universes.
Some told me they would stop using my dev-images if I use Sake/Packages without giving any good reason).
I wonder how much they are paying you for the right to make such statements... If they don't cross your palm with enough silver, he who does work decides on the tools. Just making smalltalk, s.
Hi Damien I can give you an explanation but keith will not like it. Note that I like the ideas that he is pushing and that I started to write a chapter for the next book on installer. - Keith idea that everybody can build its own distribution is not something that everybody like - For example I would like to have a real look at MC1.6 but the message around it is blurry I tried LFP and it broke on me. - I like installer but when I look at the code I would like to refactor it. - There is no document in a nice format that explain why and how (i'm fixing that for installer and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer). - unknown is strnage :) - So if you want to help me I would love to have a - Installer code refactored - Installer chapter - Sake (have a look at the code) - Sake Chapter for the book Stef On Sep 26, 2008, at 8:10 AM, Damien Cassou wrote:
On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges@yahoo.co.uk
wrote: Do have a look at Sake/Packages equivalent to universes.
I agree with Keith. Sake/Packages have all the features of universes without a GUI but provide an easy way to define your own universe as you did with Seaside and as you want to do with Pharo (just need to create a new subclass IIUC). I don't understand why people don't want to look at this solution (it's not about you Seaside developers, it's about the whole community. Some told me they would stop using my dev-images if I use Sake/Packages without giving any good reason). I hope Keith won't give up.
Bye
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
about the whole community. Some told me they would stop using my dev-images if I use Sake/Packages without giving any good reason). I hope Keith won't give up.
One problem I see with Sake/Packages is that these tools depend on a lot of other packages, that I don't necessarily want to have loaded in my images: Logging, Rio, Installer, Sake, Packages ... I guess one could argue the same with XML and Universe.
You can define a package with non-specific versions, i.e. to load the latest seaside when keeping up with the bleeding edge.
This sounds very suspicious. That can't reliably work with standard Monticello, all projects I know use multiple branches at some point. I agree that Universes is not the ultimate solution, but at least it seems to work reasonably well. I like the declarative way to specifying package dependencies. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Damien Cassou wrote:
On Fri, Sep 26, 2008 at 12:19 AM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
Do have a look at Sake/Packages equivalent to universes.
I agree with Keith. Sake/Packages have all the features of universes without a GUI but provide an easy way to define your own universe as you did with Seaside and as you want to do with Pharo (just need to create a new subclass IIUC). I don't understand why people don't want to look at this solution (it's not about you Seaside developers, it's about the whole community. Some told me they would stop using my dev-images if I use Sake/Packages without giving any good reason). I hope Keith won't give up.
I think you answered already: no GUI, no integration with tools. I see that as the only obstacle to a broader acceptance of Keith's work. JAnko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
On Fri, Sep 26, 2008 at 8:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
- For example I would like to have a real look at MC1.6 but the message around it is blurry
MC1.6 is not the topic here.
I tried LFP and it broke on me.
It worked fine for me. You may want to try again and send bug report to Keith who answered all my emails.
- I like installer but when I look at the code I would like to refactor it.
The code may not be perfect but it works fine. I don't think Keith would ignore our enhancements to his code.
- There is no document in a nice format that explain why and how (i'm fixing that for installer and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer).
This is not fair. There is "no document in a nice format that explains" most of the tools you use everyday. But you still use them. The more people use a tool, the best chance you have to get documentation. Moreover, Keith and Matthew wrote a lot of things in pbwiki, squeak wiki and mailing lists.
- unknown is strange :)
Should not be for us Squeakers and Pharoers.
- So if you want to help me I would love to have a - Installer code refactored - Installer chapter - Sake (have a look at the code) - Sake Chapter for the book
I would love that too -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Fri, Sep 26, 2008 at 8:38 AM, Lukas Renggli <renggli@gmail.com> wrote:
One problem I see with Sake/Packages is that these tools depend on a lot of other packages, that I don't necessarily want to have loaded in my images: Logging, Rio, Installer, Sake, Packages ...
I guess one could argue the same with XML and Universe.
This is the only argument against Sake/Packages I guess. Keith, could you please give us more information on that? - what mcz do we need to load exactly to have universes features using Sake/Packages? - is LPF necessary?
You can define a package with non-specific versions, i.e. to load the latest seaside when keeping up with the bleeding edge.
This sounds very suspicious. That can't reliably work with standard Monticello, all projects I know use multiple branches at some point.
Keith does not mean you *must* use it :-). This is a feature that can be useful for some small packages.
I agree that Universes is not the ultimate solution, but at least it seems to work reasonably well. I like the declarative way to specifying package dependencies.
Sake/Packages is just about that: a declarative way to specify packages. Nothing more. And there is a script which converts a Universe to a set of tasks. It works very well and Keith uses it often to update Packages from Universes. An example for PierBlog: PackagesSqueak310U>>PierBlog self name: 'Pier-Blog'. self version: '1.0.16.73'. info category: 'Web Development'. info description: 'Pier blog plugin.'. info maintainer: 'Lukas Renggli <renggli@gmail.com>'. info homepage: 'http://www.lukas-renggli.ch/smalltalk/pier'. info squeakMapID: ''. info url: 'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz'. self provides: #(). self dependsOn: #('Pier-Seaside' 'RSRSS2'). self load: [ Installer installUrl:'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz'. ]. self unload: [ Installer mc unload: 'Pier-Blog'. ]. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Fri, Sep 26, 2008 at 2:59 PM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
I think you answered already: no GUI, no integration with tools. I see that as the only obstacle to a broader acceptance of Keith's work.
For a long time, debian linux systems did not have any GUI to manage their packages. Still, their packaging system was used by thousands of people from the command line. Sake/packages makes installing packages very easy from the command line. No doubt that if more people use it, a gui will appear. What do you mean by no integration with tools and how does it differ from universes? -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote:
On Fri, Sep 26, 2008 at 8:26 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
- For example I would like to have a real look at MC1.6 but the message around it is blurry
MC1.6 is not the topic here. Still this is the same :). It is a communication problem and what people see from you.
I tried LFP and it broke on me.
It worked fine for me. You may want to try again and send bug report to Keith who answered all my emails.
Did you check what LFP is doing? I would like to know that. Because the point is not that it would not be working but what are the stuff it brings in.
- I like installer but when I look at the code I would like to refactor it.
The code may not be perfect but it works fine. I don't think Keith would ignore our enhancements to his code.
We decided to refactor it :)
- There is no document in a nice format that explain why and how (i'm fixing that for installer and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer).
This is not fair. There is "no document in a nice format that explains" most of the tools you use everyday. But you still use them. The more people use a tool, the best chance you have to get documentation. Moreover, Keith and Matthew wrote a lot of things in pbwiki, squeak wiki and mailing lists.
Come on I said that I'm writing a chapter. I can't do more.
- unknown is strange :)
Should not be for us Squeakers and Pharoers.
- So if you want to help me I would love to have a - Installer code refactored - Installer chapter - Sake (have a look at the code) - Sake Chapter for the book
I would love that too
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What is Packages? compared to Sake I tried to understand some of the emails keith sent a while back to squeak-dev but I could not get it. Setf
Sake/Packages is just about that: a declarative way to specify packages. Nothing more. And there is a script which converts a Universe to a set of tasks. It works very well and Keith uses it often to update Packages from Universes.
An example for PierBlog:
What is PackagesSqueak310U....?
PackagesSqueak310U>>PierBlog self name: 'Pier-Blog'. self version: '1.0.16.73'.
info category: 'Web Development'. info description: 'Pier blog plugin.'. info maintainer: 'Lukas Renggli <renggli@gmail.com>'. info homepage: 'http://www.lukas-renggli.ch/smalltalk/pier'. info squeakMapID: ''. info url: 'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz'. self provides: #().
self dependsOn: #('Pier-Seaside' 'RSRSS2').
self load: [ Installer installUrl:'http://mc.lukas-renggli.ch/pier/Pier-Blog-lr.73.mcz' . ].
self unload: [ Installer mc unload: 'Pier-Blog'. ].
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Damien can you post the code to load Sake Packages MC1.6 For me I'm always lost. Stef
On Fri, Sep 26, 2008 at 8:38 AM, Lukas Renggli <renggli@gmail.com> wrote:
One problem I see with Sake/Packages is that these tools depend on a lot of other packages, that I don't necessarily want to have loaded in my images: Logging, Rio, Installer, Sake, Packages ...
I guess one could argue the same with XML and Universe.
This is the only argument against Sake/Packages I guess. Keith, could you please give us more information on that? - what mcz do we need to load exactly to have universes features using Sake/Packages? - is LPF necessary?
My objection, the big ball of mud called Kernel-Extensions and the liberal use of overrides, which I think are evil. I like using packages that do their best to only use extensions and don't just go around the system willy nilly monkey patching everything. I don't trust packages with overrides not to break my system and I absolutely don't like packages that once installed can't be uninstalled, try removing Kernel-Extensions sometime. Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system. If it doesn't meet those criteria, I don't consider it safe to even experiment with. Ramon Leon http://onsmalltalk.com
My objection, the big ball of mud called Kernel-Extensions and the liberal use of overrides, which I think are evil. I like using packages that do their best to only use extensions and don't just go around the system willy nilly monkey patching everything. I don't trust packages with overrides not to break my system and I absolutely don't like packages that once installed can't be uninstalled, try removing Kernel-Extensions sometime.
Thanks! Seriously. This is the kind of feedback I like. Now we know what should be done. Cleaning, reviewing, integrating...
Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system.
100% agree. This is why I'm saying that we want to integrate extensions or reject them.
If it doesn't meet those criteria, I don't consider it safe to even experiment with.
On Fri, Sep 26, 2008 at 6:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: Did you check what LFP is doing? I would like to know that. Because the point is not that it would not be working but what are the stuff it brings in.
http://installer.pbwiki.org/LevelPlayingField LPF is a script which installs Monticello 1.5 and Installer in your image. The aim here is to get an equivalent playing field in all images. This script allowed me to install Universes, OmniBrowser and Shout in a Croquet image in a few minutes. For Pharo, we could have a look at what the script does exactly and integrate the interesting fixes. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Fri, Sep 26, 2008 at 6:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What is Packages? compared to Sake
Keith, please correct me if I'm wrong: - Sake is a domain specific language with all required tools to define make-like rules. It allows people to describe tasks (as done in the Ant/Java world) and execute these tasks when necessary (http://wiki.squeak.org/squeak/5953) - Packages uses Sake to reimplement a universe-like tool with dependencies. Then, it describes a lot of Squeak packages with their dependencies.
What is PackagesSqueak310U....?
this is a class which has been generated automatically by a Sake task from the Dev Universe. This means that each change I do in the Universe system is reflected automatically in Sake just by running a task. Moreover, the fact that each package is describe in a method using only Smalltalk code makes creating new set of packages very easy. For Pharo, we could just subclass PackagesSqueak310U and override the methods we want to change. For Seaside, they could just provide yet another class... I think it's much easier than with Universes. Finally, the package descriptions are hosted on SqueakSource instead of one's particular server. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Fri, Sep 26, 2008 at 6:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
can you post the code to load Sake Packages MC1.6
http://installer.pbwiki.com/Packages: Installer install: '311-KernelExtensions'. Installer squeaksource project: 'Sake'; install: 'Sake'. Installer squeaksource project: 'Packages'; install: 'Sake-Packages'. And you will get Sake and Packages. Look at the class PackagesDevU which contains the description of all packages from the dev-universe (it seems it is the new name for PackagesSqueak310U). For MC1.6, I don't know because it does not seem to be released yet. Look at http://installer.pbwiki.com/Monticello16-Beta and ask Keith and Matthew if you are really interested. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
On Fri, Sep 26, 2008 at 6:50 PM, Ramon Leon <ramon.leon@allresnet.com> wrote:
My objection, the big ball of mud called Kernel-Extensions and the liberal use of overrides, which I think are evil.
I don't know about Kernel-Extensions but if I look at http://installer.pbwiki.com/311-KernelExtensions, I can see that «It should be safe to install on any 3.7 or later image, as it only adds methods.» If this sentence is wrong, you should contact Keith.
I like using packages that do their best to only use extensions and don't just go around the system willy nilly monkey patching everything. I don't trust packages with overrides not to break my system and I absolutely don't like packages that once installed can't be uninstalled, try removing Kernel-Extensions sometime.
If you only install Kernel-Extensions, it should be safe and easy to uninstall. Now, if you install packages that depend on Kernel-Extensions, it is understandable that Kernel-Extensions becomes harder to remove :-). This is even more true, if MC1.5 depends on Kernel-Extensions (but I don't know).
Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system. If it doesn't meet those criteria, I don't consider it safe to even experiment with.
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
Thanks I will. since like me you would like to see some of the ideas od keith to be put forward. If you have some time, read the code andgive feedback I would like to continue to cruve out etoy for now. On Sep 27, 2008, at 11:43 AM, Damien Cassou wrote:
On Fri, Sep 26, 2008 at 6:25 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 26, 2008, at 5:03 PM, Damien Cassou wrote: Did you check what LFP is doing? I would like to know that. Because the point is not that it would not be working but what are the stuff it brings in.
http://installer.pbwiki.org/LevelPlayingField
LPF is a script which installs Monticello 1.5 and Installer in your image. The aim here is to get an equivalent playing field in all images. This script allowed me to install Universes, OmniBrowser and Shout in a Croquet image in a few minutes.
For Pharo, we could have a look at what the script does exactly and integrate the interesting fixes.
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Keith, please correct me if I'm wrong:
- Sake is a domain specific language with all required tools to define make-like rules. It allows people to describe tasks (as done in the Ant/Java world) and execute these tasks when necessary (http://wiki.squeak.org/squeak/5953)
Yes we need that
- Packages uses Sake to reimplement a universe-like tool with dependencies. Then, it describes a lot of Squeak packages with their dependencies.
Ok
What is PackagesSqueak310U....?
this is a class which has been generated automatically by a Sake task from the Dev Universe. This means that each change I do in the Universe system is reflected automatically in Sake just by running a task.
Moreover, the fact that each package is describe in a method using only Smalltalk code makes creating new set of packages very easy. For Pharo, we could just subclass PackagesSqueak310U and override the methods we want to change. For Seaside, they could just provide yet another class... I think it's much easier than with Universes. Finally, the package descriptions are hosted on SqueakSource instead of one's particular server.
Good! So let us check that. Don't you want to write something for the next book Squeak by Example VOl 2 (err....Phar ....) Stef
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ 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:
Hi Damien
I can give you an explanation but keith will not like it. Note that I like the ideas that he is pushing and that I started to write a chapter for the next book on installer. - Keith idea that everybody can build its own distribution is not something that everybody like It is what the community has been talking about and doing for the past few years. I started by providing a Seaside-Magma-Pier image, now instead I can provide a Seaside-Magma-Pier entry in Sake/Packages which will work in any image that the squeak community typically uses.
There are people now building one-click Pier images, and one click Seaside images, but this is going back to doing it the old way, and it will not be generally useful, since every major project builds their own image. For example Gjallar, Sophie, WebStore (my Project) etc.
- For example I would like to have a real look at MC1.6 but the message around it is blurry
I am sure that Matthew will be able to make the message clearer, in the meantime please do not overlook the months of work that have gone into MC1.5.
I tried LFP and it broke on me.
That was simply the wiki complaining that it was being hit too hard. LPF has been working for many people for months, you just got unlucky. It may be fixed.
- I like installer but when I look at the code I would like to refactor it.
Of course, Installer is designed with that future refactoring in mind. Keeping everything in one class was an initial design goal for the purpose of "looking slim" and gaining acceptance. Now that Installer has gained some acceptance it may be time to tidy up the code. I still like the one class feature, but at some point the maintainability will suffer too much.
- There is no document in a nice format that explain why and how (i'm fixing that for installer
Installer has a class comment and this is available on the squeak wiki, and http://installer.pbwiki.com/Installer what more do you want?
and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer). - unknown is strnage :) - So if you want to help me I would love to have a - Installer code refactored - Installer chapter - Sake (have a look at the code) - Sake Chapter for the book
Sounds good to me! Keith
I agree that Universes is not the ultimate solution, but at least it seems to work reasonably well. I like the declarative way to specifying package dependencies.
Cheers, Lukas
Sake/Packages has been changed to be declarative for the most part, though it isn't restricted to that. Keith
Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system. If it doesn't meet those criteria, I don't consider it safe to even experiment with.
Ramon Leon http://onsmalltalk.com
If it uses overrides, the MC1.5 should be able to uninstall it. However MC1.5 probably depends upon it. So you are probably stuck there. Kernel-Extensions are not supposed to be removed, they are supposed to be integrated into the main image. We have two ways of doing this. We are slowly breaking it down into bug fixes on mantis, however these are changesets and are not removeable either. Keith
100% agree. This is why I'm saying that we want to integrate extensions or reject them.
If it doesn't meet those criteria, I don't consider it safe to even experiment with.
However, if the base system doesnt support loading and unloading of things in the first place, its a bit unfair to expect a package to be unloadable, when its purpose is to fix the base package so as to be able to support loading and unloading. Once everything we use has LPF (or equivalent) then it is reasonable to expect loading an unloading to work. I admit that Kernel-Extensions has become bloated with more than just the minimum, however it has the advantage of being version controlled which changesets are not. Keith
On 28.09.2008, at 19:01, Keith Hodges wrote:
Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system. If it doesn't meet those criteria, I don't consider it safe to even experiment with.
Ramon Leon http://onsmalltalk.com
If it uses overrides, the MC1.5 should be able to uninstall it. However MC1.5 probably depends upon it. So you are probably stuck there.
keep in mind that unsinstall can not work in gereral... overrides are evil. So just think you installed some packate that has an override. Now you install a second, that overrides again. Ups, broken. So we change the new override to take into account the change done in the first. Now when de-installing the first package, what should happen?
Kernel-Extensions are not supposed to be removed, they are supposed to be integrated into the main image. We have two ways of doing this.
We are slowly breaking it down into bug fixes on mantis,
considering that mantis now has >1000 open entries... Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On Sep 28, 2008, at 6:50 PM, Keith Hodges wrote:
Stéphane Ducasse wrote:
Hi Damien
I can give you an explanation but keith will not like it. Note that I like the ideas that he is pushing and that I started to write a chapter for the next book on installer. - Keith idea that everybody can build its own distribution is not something that everybody like It is what the community has been talking about and doing for the past few years. I started by providing a Seaside-Magma-Pier image, now instead I can provide a Seaside-Magma-Pier entry in Sake/Packages which will work in any image that the squeak community typically uses.
There are people now building one-click Pier images, and one click Seaside images, but this is going back to doing it the old way, and it will not be generally useful, since every major project builds their own image. For example Gjallar, Sophie, WebStore (my Project) etc.
- For example I would like to have a real look at MC1.6 but the message around it is blurry I am sure that Matthew will be able to make the message clearer, in the meantime please do not overlook the months of work that have gone into MC1.5.
I will look do not worry. :) I'm just slow
I tried LFP and it broke on me. That was simply the wiki complaining that it was being hit too hard. LPF has been working for many people for months, you just got unlucky. It may be fixed. - I like installer but when I look at the code I would like to refactor it. Of course, Installer is designed with that future refactoring in mind. Keeping everything in one class was an initial design goal for the purpose of "looking slim" and gaining acceptance. Now that Installer has gained some acceptance it may be time to tidy up the code. I still like the one class feature, but at some point the maintainability will suffer too much.
Ok I could do a pass on that then.
- There is no document in a nice format that explain why and how (i'm fixing that for installer Installer has a class comment and this is available on the squeak wiki, and http://installer.pbwiki.com/Installer what more do you want? and I was waiting because I will refactor it else I do not publish the chapter but I did not want to insult keith since this is not the point since I like installer). - unknown is strnage :) - So if you want to help me I would love to have a - Installer code refactored - Installer chapter - Sake (have a look at the code) - Sake Chapter for the book Sounds good to me!
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I sent an email a while back on checkeing Kernel Extensions. I know added an entries in the bgtracker. Stef On Sep 28, 2008, at 7:01 PM, Keith Hodges wrote:
Now, the code may work perfectly fine, and Keith's done a lot of work, but it's just not community friendly code. A package should have a clear responsibility, few dependencies, not too many extensions, no overrides if at all possible, and must install and uninstall cleanly without hosing my system. If it doesn't meet those criteria, I don't consider it safe to even experiment with.
Ramon Leon http://onsmalltalk.com
If it uses overrides, the MC1.5 should be able to uninstall it. However MC1.5 probably depends upon it. So you are probably stuck there.
Kernel-Extensions are not supposed to be removed, they are supposed to be integrated into the main image. We have two ways of doing this.
We are slowly breaking it down into bug fixes on mantis, however these are changesets and are not removeable either.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
considering that mantis now has >1000 open entries...
Marcus
?? The difference being, that we dont create a mantis entry so that it can languish unused. We use mantis as a vessel for holding snippets of code and collecting feedback. Installer collects a list of fixes applied, and Sake/Tasks has a task for documenting those fixes in the image. Keith
On 28.09.2008, at 22:16, Keith Hodges wrote:
considering that mantis now has >1000 open entries...
Marcus
??
The difference being, that we dont create a mantis entry so that it can languish unused. We use mantis as a vessel for holding snippets of code and collecting feedback.
Installer collects a list of fixes applied, and Sake/Tasks has a task for documenting those fixes in the image.
So fixes are not integrated into the image anymore and the report then closed? What I don't understand with the use of Installer with mantis entries: From my experience from 3.6 to 3.9, there is quite some dependency between fixes. Thas means: two fixes are overriding the same method, to harvest both, the second one applied can not be added but needs to be redone to take the changes of the first into account. I really can't imagine how you can automatically apply changesets from the bugtracker to build "your own release". This just can't work with all the dependencies between fixes. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Marcus Denker wrote:
On 28.09.2008, at 22:16, Keith Hodges wrote:
considering that mantis now has >1000 open entries...
Marcus
??
The difference being, that we dont create a mantis entry so that it can languish unused. We use mantis as a vessel for holding snippets of code and collecting feedback.
Installer collects a list of fixes applied, and Sake/Tasks has a task for documenting those fixes in the image.
So fixes are not integrated into the image anymore and the report then closed?
When a release image is released the fixes are integrated into the image as normal, and can be closed or marked "fixed". Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something. Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer. This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team.
What I don't understand with the use of Installer with mantis entries: From my experience from 3.6 to 3.9, there is quite some dependency between fixes. Nothing is automatic, if you or some script loads the wrong fix in the wrong order then that is a problem. Thas means: two fixes are overriding the same method, to harvest both, the second one applied can not be added but needs to be redone to take the changes of the first into account.
I really can't imagine how you can automatically apply changesets from the bugtracker Nothing is automatic.
to build "your own release". This just can't work with all the dependencies between fixes. However, the old way, fixes are applied to a moving target, since the alpha image is continuously being updated. With this approach fixes applied to 3.10 (a fixed target) are used to create a 3.11 unstable until the combination of fixes is deemed "stable"
Keith
If it uses overrides, the MC1.5 should be able to uninstall it. However MC1.5 probably depends upon it. So you are probably stuck there.
keep in mind that uninstall can not work in general... overrides are evil.
My feelings exactly. I don't want an MC that tries to be smart, I want packages who's authors recognize that overrides are pure evil and don't use overrides. If the built in method doesn't work for you, then create an extension that does with a prefix that suites your package. It might not be pretty, but it's better that changing core code and breaking other peoples packages. Ramon Leon http://onsmalltalk.com
So fixes are not integrated into the image anymore and the report then closed?
When a release image is released the fixes are integrated into the image as normal, and can be closed or marked "fixed".
Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports?
Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something.
So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, in addition to actually doing 3.11. Is that realistic?
Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer.
This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team.
This is *the* recipe for failure. You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too.
What I don't understand with the use of Installer with mantis entries: From my experience from 3.6 to 3.9, there is quite some dependency between fixes. Nothing is automatic, if you or some script loads the wrong fix in the wrong order then that is a problem.
And of course this means that nobody can load any other order, so it makes no sense to have all the fixes as entities on their own at all.
to build "your own release". This just can't work with all the dependencies between fixes.
However, the old way, fixes are applied to a moving target, since the alpha image is continuously being updated.
Yes, this is very important. As loading a fix for 3.10 into the developement version of 3.11 will almost never work, as other fixes already changed the sytem. This is true even with the installer. So you will end up in using the "moving target" of 3.10+ Intaller as your "HEAD" system that people use when doing changes. Else you will end up in many changesets that have conflicts, and, very annoyting, hundreds of douple-reports of bugs.
With this approach fixes applied to 3.10 (a fixed target) are used to create a 3.11 unstable until the combination of fixes is deemed "stable"
But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. We will see at the end what was the better Idea ;-) Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports? Wow what? The release will know which bug fixes are included and provide a list of fixes which can be closed, when the release is actually ready and available.
Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something.
So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. So why does Seaside, Magma etc run in older images?
Please think sensibly, we are not trying to make "everything" work in all images. Just to enable the things that we want to work when necessary. Last year I found myself working in 3.8, 3.9 and 3.10, maintaining different packages in different images. For example I would have to have an image especially configured just for developing contributions to Seaside. I ended up running about 12 different images. Simply because MC would not handle method extensions and overrides correctly. So essential step... "make MC run identically in all images, and make overrides and extensions work"... in the process benefit the whole community.
Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). It wont kill me since I am not using it.
The point is that there are people actually using 3.7 and 3.8 for things. Up until recently Gjallar was using 3.8. The transition to 3.10 was achieved by building the image in 3.8 using an installer script, then migrating that script and the packages involved to work with both 3.8 and 3.10. Finally the script was run to generate a 3.10 image.
In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, Not really.
To get Monticello 1.5 working in 3.7 requires something like 5-6 methods to be added to the base image. Necessary changes to Kernel are usually very minimal.
in addition to actually doing 3.11. Is that realistic?
Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer.
This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team.
This is *the* recipe for failure. There is no need to be so dramatic.
We have been doing this for a while now and have seen nothing but success. LPF is useful it works and has worked for lots of people, whereas before the Croquet community and the XO community were destined to be out on their own. I now know that I can load my website up on my XO, and I fully expect to be able to try Rio out in Croquet.
You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too. I never said that it would "have to", but it can if necessary. However, the old way, fixes are applied to a moving target, since the
But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. That's a bit dramatic, I am not planning on dying any time soon. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". We dont need to say that at all. We can say, here is an image, (or here is a script which builds the image) in which your fix is loaded and needs further work. Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. I don't see that, but then I am not looking at the BugTracker to read bug reports. I periodically export reports into squeak, so I am look at them in my class browser where each report is a method that I can categorize. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Sounds fair enough. But I dont think you are understanding the "release" is an atomic event. Fixes can get tweaked improved up until the release. Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). Your approach is based around small incremental changes to an image, performed by a single person. In particular it is easier to add things than to remove things. Overall it results in an adhoc process that lacks planning. It lacks control over the big picture. Everyone ends up following the one person doing the release. The release team do what they want in whatever order they want to do it. No one knows what the plan is in advance and there is no mechanism provided for people to contribute into the work.
We have 3.11 fully planned, the script to generate the test-candidate runs, from end to end. Contributors can add their fix-tasks to that script.
And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. This is a cop out, it is taking a process that could be a slope and making it a step, but you are pretending that it will be a slope by saying nice things like "release often" and "integrate asap". Squeak has never been release often or integrate as soon as possible. The reason for this is nothing to do with squeak, it is to do with PROCESS. The Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the Pharo process has changed, the pharo process will not be any different.
However, the 3.11 development has been entirely about creating a process that will support "release often" and that we could do monthly time boxed releases with.
We will see at the end what was the better Idea ;-) I have always maintained that Pharo's goals and 3.11's goals are essentially the same.
Keith
Stéphane Ducasse wrote:
We will see at the end what was the better Idea ;-)
Good challenge :) I will integrate a bit more etoys now.
Stef
Not a challenge I am taking up, I have a ball joint to replace on my car, and no time to input into this at the moment. Keith
FWIW I am 100% behind "release often, integrate as soon as possible". Not only this but you only have to do a small amount of googling to begin to realise that *finally* the computing world is getting the sea change required to make this approach the main stream, rather than the BUF* (release planning in this case). I'm not trying to invalidate people taking other approaches: I simply don't think they're the best way to do things. If those people working hard on Pharo can stick to the guns of this approach (and it's not an easy approach), I think it will be the right one. I'm sorry I don't have more time to give myself, but I try to keep myself useful from time to time. Cheers, Simon On 29 Sep 2008, at 20:55, Keith Hodges wrote:
Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports? Wow what? The release will know which bug fixes are included and provide a list of fixes which can be closed, when the release is actually ready and available.
Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something.
So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. So why does Seaside, Magma etc run in older images?
Please think sensibly, we are not trying to make "everything" work in all images. Just to enable the things that we want to work when necessary.
Last year I found myself working in 3.8, 3.9 and 3.10, maintaining different packages in different images. For example I would have to have an image especially configured just for developing contributions to Seaside. I ended up running about 12 different images. Simply because MC would not handle method extensions and overrides correctly.
So essential step... "make MC run identically in all images, and make overrides and extensions work"... in the process benefit the whole community.
Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). It wont kill me since I am not using it.
The point is that there are people actually using 3.7 and 3.8 for things. Up until recently Gjallar was using 3.8. The transition to 3.10 was achieved by building the image in 3.8 using an installer script, then migrating that script and the packages involved to work with both 3.8 and 3.10. Finally the script was run to generate a 3.10 image.
In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, Not really.
To get Monticello 1.5 working in 3.7 requires something like 5-6 methods to be added to the base image. Necessary changes to Kernel are usually very minimal.
in addition to actually doing 3.11. Is that realistic?
Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer.
This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team.
This is *the* recipe for failure. There is no need to be so dramatic.
We have been doing this for a while now and have seen nothing but success. LPF is useful it works and has worked for lots of people, whereas before the Croquet community and the XO community were destined to be out on their own. I now know that I can load my website up on my XO, and I fully expect to be able to try Rio out in Croquet.
You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too. I never said that it would "have to", but it can if necessary. However, the old way, fixes are applied to a moving target, since the
But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. That's a bit dramatic, I am not planning on dying any time soon. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". We dont need to say that at all. We can say, here is an image, (or here is a script which builds the image) in which your fix is loaded and needs further work. Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. I don't see that, but then I am not looking at the BugTracker to read bug reports. I periodically export reports into squeak, so I am look at them in my class browser where each report is a method that I can categorize. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Sounds fair enough. But I dont think you are understanding the "release" is an atomic event. Fixes can get tweaked improved up until the release. Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). Your approach is based around small incremental changes to an image, performed by a single person. In particular it is easier to add things than to remove things. Overall it results in an adhoc process that lacks planning. It lacks control over the big picture. Everyone ends up following the one person doing the release. The release team do what they want in whatever order they want to do it. No one knows what the plan is in advance and there is no mechanism provided for people to contribute into the work.
We have 3.11 fully planned, the script to generate the test-candidate runs, from end to end. Contributors can add their fix-tasks to that script.
And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. This is a cop out, it is taking a process that could be a slope and making it a step, but you are pretending that it will be a slope by saying nice things like "release often" and "integrate asap". Squeak has never been release often or integrate as soon as possible. The reason for this is nothing to do with squeak, it is to do with PROCESS. The Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the Pharo process has changed, the pharo process will not be any different.
However, the 3.11 development has been entirely about creating a process that will support "release often" and that we could do monthly time boxed releases with.
We will see at the end what was the better Idea ;-) I have always maintained that Pharo's goals and 3.11's goals are essentially the same.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA
I like the Installer. Its a simple tool to break your work onto multiple stages/packages. It is very useful for making automatic builds. No manual image hacking - instead you have to fix the scripts or packages. This will guarantee that every time you will load the same code as before, w/o losing or forgetting something. -- Best regards, Igor Stasenko AKA sig.
Yes I like it too. This is why I want to invest on it. On Sep 30, 2008, at 4:27 AM, Igor Stasenko wrote:
I like the Installer. Its a simple tool to break your work onto multiple stages/packages. It is very useful for making automatic builds. No manual image hacking - instead you have to fix the scripts or packages. This will guarantee that every time you will load the same code as before, w/o losing or forgetting something.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Keith could you make sure that the tests can run when we load the installer and its tests? I do not know what is the classcloner... Stef
Hi keith Since I'm more in doing than talking.... I read the code of Installer I reformatted the code and publish it. I did not change anything so far. I suggest you to consider formatting as an important code readibility issue. Often I cannot see the complete method or I cannot understand its flow. Stef Now here is a list of questions/suggestions ============================== Installer class>>classes ^ Smalltalk not invoked seems bogus ============================== Entities seems a bad name for html elements mapping. ============================== history seems obsolete Installer class>>mczInstall is misclassified ============================== Installer class>>sake ^ self sake: (Sake ifNil: [ self classPackages current ]) Does not make sense to me if Sake is not loaded. setSakeToUse: aClass Sake := aClass is missing a comment to indicate what is the purpose of Sake? On the instance side ============================== user ^ user ifNil: [ '' ] user: anObject user := anObject user is undefined, thanks shout! ============================== classMCMczReader ^Smalltalk at: #MCMczReader ifAbsent: [ nil ] classMCReader ^Smalltalk at: #MCReader ifAbsent: [ nil ] classMczInstaller ^Smalltalk at: #MczInstaller ifAbsent: [ nil ] why nil and not error as all the others? ============================== createRBforBug: aBugNo | aStream fileList selFile aFileName | self setBug: aBugNo. fileList := self maFiles keys asOrderedCollection. fileList addLast: 'none'. ReleaseBuilderFor3dot10 clear. [selFile := UIManager default chooseFrom: fileList title: 'Choose what files load '. selFile = fileList size ifFalse:[ aFileName := fileList at: selFile. self logCR: 'obtaining ', aFileName, '...'. aStream := self maStreamForFile: aFileName . ReleaseBuilderFor3dot10 current packagesInfluenced: aStream named: aFileName. self installCS: aFileName from: aStream].selFile = fileList size]whileFalse. ReleaseBuilderFor3dot10 current newUpdateFor: aBugNo ReleaseBuilderFor3dot10 does not exist. ============================== installMCcs: aFileName from: stream | reader | reader := MCCsReader on: stream. should use self MCCsReader because MCCsReader may not exist ============================== skipTests is empty
participants (12)
-
Adrian Lienhard -
Damien Cassou -
Igor Stasenko -
Janko Mivšek -
Keith Hodges -
Lukas Renggli -
Marcus Denker -
Norbert Hartl -
Ramon Leon -
Simon Kirk -
Stefan Schmiedl -
Stéphane Ducasse