Begin forwarded message:
From: "Damien Pollet" <damien.pollet@gmail.com> Date: November 12, 2008 12:26:28 AM CEST To: "Keith Hodges" <keith_hodges@yahoo.co.uk> Cc: "Stéphane Ducasse" <stephane.ducasse@inria.fr>, "Tudor Girba" <girba@iam.unibe.ch
, "Damien Cassou" <damien.cassou@gmail.com> Subject: Re: Sake, Packages, and deployment code
On Tue, Nov 11, 2008 at 11:04 PM, Keith Hodges <keith_hodges@yahoo.co.uk
wrote: SSpec doesnt follow that convention, but uses method category 'specs'. So in SUnit-improved it has a more flexible approach in order to accomodate SSpec and not to have to follow this convention, it allows you to define toDo* bug* , method categories, flagged methods, pragmas or whatever else you choose.
All good solutions⦠actually I agree that relying on the method name is somewhat of a hack.
I have never looked at PRDistribution. Lukas and folks changed something which has broken all my pier deployments and so I am stuck with an older version of pier until I can find some spare time to fix it.
Basically, it's just creating a PRKernel with a bunch of pages using lazy initializers.
Right now I am betting that PRDistribution is an incompatible alternative to my PRFrames, which is a shame.
Well, it's explicitly creating a PRPierFrame I think, but that's just in a couple methods.
Neither am I. I would like "universes" to die off. The reason being the overly controlled closed nature of the master database, and the
What bothers me most is that it's centralized.
But what I am convinced of is that if you put the control of the dependencies in the hands of the developers, then it will get out of date, when the developers get too busy, and hold on to too much control.
Maybe, but they are also the ones which will most probably need to create clean work images from scratch most often, be it for automated test purposes, because their image broke, or simply to keep up-to-date with the platform images.
The ethos behind Sake/Packages is that it is the package USERS that determine what works in what context. Developers often don't test their packages in all contexts, but users may do.
It is a space in which the collective knowledge of what works where is collated by the community. Both the Users "universes" and the developers SetUp packages can be used to get the best of both worlds.
Exactly. Developers can propose their part of the collective knowledge (precise, minimal, low-level dependancies between individual MC branches). Then the community can build higher-level packages or whole integrated distributions, either by using what the developers provide, or by doing the integration tests independantly and providing a different set of dependencies. For instance, I expect developers would not mention versions at all, except for planned incompatibilities. Distributions would freeze whole sets of versions together because they are known to work.
determine success. For instance, I think SourceTalk and Bob should be linked or even integrated someday, so that getting automatic builds for a new project is near-instant Just need to add MC2 support to, Installer.
For the fastest loading experience, try MC1.6!
I also have a plan for binary loading for both MC1 and 2.
I meant instant in cognitive time :D I want only one bookmark, one account, be able to link build numbers to bug reports and unit tests versions all in one place.
By the way, I'm trying stuff with Packages now, and I'm realizing I need a way to depend on rules from another class. Concretely, the Pier-Model task in PierSetup should depend on Magritte-Model in MagritteSetup. The situation is kind of similar to makefiles and recursive makefiles⦠it works but sub-makes don't have access to the state of the parent make process. Is there a way to merge or union several SakeTasks ?
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet