update stream policy
ducasse
ducasse at iam.unibe.ch
Sat Jan 17 19:37:25 UTC 2004
Hi avi
for me this is a tradeoff between time and energy.
**now** the 17 January 2004, I write tests, I review tests,... Now I
do not have the time to create a new package
with monticello and publish it each time there is a new test coming
out. Once tests have reviewed and approved there is normally
**no** conflicts. So harevsting them is simple.
So if you provide a solution that in one click I can say add this test
to this package and publish (like I could do it in VW with Store)
then I would use it. It should work in alpha in basic because this is
with such an image that I'm reviewing code.
For me the most important point is that test should be in basic image,
full image and alpha. If we consider tests as documentation
why don't we bundle them together. Why do not we also put class comment
in a separate package.
This is an education point. I will not repeat again what I say about
that. Everybody can read any XP book or other stuff to see the value of
tests.
>
> Markus, Stef, do you have objections to that? Guides, am I correct in
> thinking that this was the intent, moving forward?
After I have no objection on the goal, and I'm working on it. The KCP
stuff is going in that direction. Cleaning &*^&^^* SystemDictionary or
Utilities is not something you do just because you have nothing to do
and I have far too much stuff to do.
So where should I sign, where so that I get a clean mini squeak and
some nice load script with packages.
But where is squeak mini ckernel + nice load script and dependencies.
Avi I started to use monticello and I'm sad to see that I cannot
express dependency between my package (lukas told me that
a solution is to have only one package, believe me I laugth a lot after
having worked with this ugly/horrible Envy). So I sue the means I have
now.
an important point is that for the changeNotifier roel told me that he
spent much more times (around 5 times more) writing the tests that the
code, so we would be silly to lost and not have them present so that
people can read how to use it.
Now the changeset systemNotifier are blocked in the update stream
because they contain tests!!! Coooooollllll
Stef
> It's not about whether the tests are in the image "by default". It's
> a matter of *how* the tests get added to the image, and how they get
> maintained.
>
> Traditionally, when we add a new bunch of code to the image, we do so
> by bundling it up into a big changeset and dumping that into the
> update stream. When there are changes to the code later, they get
> posted as an ENH or a FIX, go through the approval process, and
> finally end up in the update stream as well. This process has a
> number of problems:
>
> - it makes building a minimal image harder
> - it increases licensing complexity (anything put into the update
> stream in this way is almost certainly "infected" by the Squeak-L)
> - it puts added load on the BFAV approval process, and on Doug or
> whoever maintains the update stream
>
> The alternative way *of getting code into the image* is to put it as a
> package on SM, preferably in an "updatable" package format like .mcz,
> and issue a simple, small item into the update stream that loads it
> from the map. Any changes to the code get made to the external
> package, and SM gets updated with the new version. Anyone who wants
> these changes can grab them from SM as soon as they want; eventually,
> a new small item can be added to the update stream that loads the new
> package version into everyone's image.
>
> My understanding was that we were going to move away from the first
> way of doing things and towards the second, with the goal that
> eventually most of the code in the image would be maintained as
> external packages (*even if it was also included in whichever default
> image people download*), rather than with the update stream.
>
> To be perfectly clear, I would propose that we institute the following
> policy for the update stream. The only acceptable kinds of updates
> are:
>
> - those that make fixes to code already in the image
> - those that remove code from the image
> - those that load or update packages from SM
More information about the Squeak-dev
mailing list
|