Sent before finish it, sorry El dom, 16-05-2010 a las 09:14 -0700, Eliot Miranda escribió:
Hi Mariano,
I think Andreas' recent post to squeak-dev is most cogent o this topic:
I don't see why. Lets see, Andreas said: "While looking into Metacello I also spent some time at the Pharo Metacello repository on Squeaksource. There are many interesting things to be said about it, both good and bad. Good things about it are that it's community maintained. Everyone can update everyone else's contributions and although that's not generally done, it offers a community approach to making sure things work. Something that for example both Universes and Squeakmap lack completely. What's problematic about the repository on the other hand is that for one thing one needs to unconditionally trust the code even before one has even decided to install it (this by far my biggest complaint about Metacello)." I don't buy this, how is this different than loading a package (Seaside, RFB, whatever) from SqueakSource in my image. Unless I browse the full code in SqueakSource (slow as hell), I don't have any guarantees that the code doesn't does a true become: false in some initialization method somewhere. The same applies to the ConfigurationOfXXX packages. The advantage of loading it to your image is that at least you can use a real environment to analyze the code. If you are using the loader to update your critical mission deployment, well, given the current security foundations of Smalltalk, you're betting to the wrong horse. If you want more security is a matter of signing the package in Squeaksource somehow and checking the signature on loading in the image (like every reasonable linux distro does currently on installing packages), or using some kind of sandbox for loading untrused code. But that is completely other issue and has nothing to do with the Metacello way of work. In fact, Metacello it could be enhanced to check some kind of signature before loading and then the trust problem will be real targeted. "Also, I don't think that a single repository is a feasible option in the long term - it seems to me that supporting the cross-product of image and package versions is going to be problematic before too long. And of course browsing repositories with several dozen of packages to find what you need isn't exactly fun either." Of course, nobody denies that, and in fact is an issue that has been discussed several times before in this list. Check the Loader code that is being worked on. It searches, installs, and is easier to write than directly use ConfigurationOfXXX messages. "However, the problems can be turned on their head, and that's actually pretty insightful. Here's the basic idea: What if, instead of having a single repository for all image versions with separate packages for each config, we would instead have a single package simply called Configurations in the trunk? That Configurations package would contain all the "supported" configurations for Squeak (I'll get to that in a minute). The package would be community-maintained, just like any other package in trunk development process. This addresses the trust issues with Metacello, since the package has the same level of trust that all the other packages in a Squeak release have; it has been developed using the same principles." Won't work, because not everybody works on Squeak, in fact, most ConfigurationOfXXX have been created and tested first on Pharo. The idea Andreas propose is to have a Squeak configuration and Pharo a Pharo configuration, that very likely will be a hell of copy & paste of methods. The good thing of having separate ConfigurationOfXXX packages in a neutral repository (MetacelloRepository) is that everybody can add methods (one for each version and for each one of Squeak and Pharo if necessary) to a only one Configuration. What you propose is to forget that there are users of a package in both camps and that your solution propose that the maintainer create two or more configuration packages in distinct repositories (one for Squeak in trunk repo and one for Pharo in MetacelloRepository). This is not funny. Also, this just add other package to the base image, a package that will change a lot between different Squeak releases. Squeak 5 will have a package with 10 configurations, Squeak 6 will have a package with 45 configurations. The idea of core package or base package is that the package is not changing a lot between releases. Current ConfigurationOfXXX only needs Gofer or Installer in the base image. Maybe a future Pharo release will have Gofer and Loader in the base image but Loader doesn't grow unrestricted between Pharo releases. The MetacelloRepository will do. "What that gives us is a mechanism by which we suddenly can include Omnibrowser, Seaside, Magma, FFI and anything else people can come up with in Squeak without having to preload it in the shipping image." This is funny, I haven't realised that to this day it is imposible to have a Pharo Core image without packages installed by default. Good to know that this will be possible soon with this new Configurations package. "What it also means is that we can start removing packages from the image, replacing them with the proper configurations for how to load them back. What it means is that somebody with a new application (be that Stephane's Muo app, Hillaire's Dr. Geo, or Josh's OpenCL demo) can ask for the configuration to be part of the next Squeak release, thereby contributing *directly* to that Squeak version." And this is really what I don't understand of the Squeak fellows, why, why should someone *ask* someone (people or board or institution) for permission to add a package to a released Squeak. Why? Why should I wait for the next release for my package to be *accepted*? This is non-sense. The current state of affairs permit me, even now that Pharo 1.0 has been released, to release my own package *aimed* on Pharo1.0 by just testing that works and publishing my ConfigurationOfXXX in the MetacelloRepository. The proposed solution is just plain wrong and completely "Squeakish" (lets have everything in the image) "Most importantly, however, is that we as the community can decide what we feel we want to support and what not. " What you base your judgements on to conclude this. The community decide what ConfigurationOfXXX is created, tested and maintained or supported. "To do that, I'm proposing to create a status of "Community Supported Package" in Squeak. What is that? A community supported package is a piece of software where we feel this is an important/interesting/novel package that should ship with this Squeak version. A community supported package can be loaded in a 'one-click' process directly from within the image. A community supported package is a package where we provide assurance that the package has been tested for this release." How is this different from the current #released, #stable, #development tags you can use in Metacello to mark the status level of a given package in a given released Pharo or Squeak version? "However, that status does not come for free. In return for achieving this status, the software needs follow the rules for community supported packages, which (at least) should include the following: * No conflicts. Neither class names nor -override categories. The rationale is that all community supported packages can be loaded together without creating conflicts." This is an artificial restriction. Debian and derived ones and Red Hat and derived ones distros permit to install conflicting packages from the same universe without problems. You see, is the decision of the user and not the maintainer or distro packager what to install. For example you can't install (well you can, but you shouln't most times) Sendmail at the same time that Exim or Postfix. They are conflicting packages and the system only warns you about the conflicts. But the system permits you install them if you want. The same applies to the overrides. If I want to install two packages that have overrides over the same methods that is my problem. The system should only warn me and let me do what I want. "* Tests mandatory. A community supported package MUST have tests. The rationale is that since we provide the guarantee that the package has been tested, we need to ensure that testing can be automated to the maximum extent possible. It doesn't mean 100% coverage but *some* meaningful set of tests need to be provided or else we can't say if we broke it in the latest update." This is good no matter the package system on hand. But this is also an artificial restriction. A package can work (and for a lot of people can be useful) even if no single test is provided. Would you denied them the posibility of install the package in your image. This only will push users away from your image "4. Provide a better installer than these awful doIts for Metacallo." This is the job of the tools, as Dale has said from the beginning. And there are tools to simplify the install of package both in a workspace doit or with GUI "5. Establish a test server to automatically verify the community standards for supported packages (i.e., load packages randomly, ensure no conflicts, run tests, report results)." This is something also being worked on since a while. A Hudson server has been proposed for this. "At this point, there is another clearly defined way to contribute to Squeak even if you're not a core developer: Develop your software, provide a configuration, ensure your software adheres to the community standards." But this already exists, or we live in different worlds? So, what is really new or advantageous in this proposal? I really don't see it. -- Miguel Cobá http://miguel.leugim.com.mx