[squeak-dev] Nebraska-edc.15 in trunk unloadable

Edgar J. De Cleene wrote: I understand perfectly what team means, years of sailing teaches you
that you cannot do it all, and you need others to contribute, but every
boat needs a captain, and every boat needs someone to clean the toilet.
As a result, if the crew are seasick, or are not part of the team, it is
not unusual to find the captain cleaning the toilet, and the boat
sitting in port.

Keith

Bert Freudenberg wrote:
> Besides, in my image loading the latest Kernel package removes
> Semaphore>>wait, which is fatal. Anyone else seeing this?

Overrides. Evil Overrides. I put in a version that puts wait back where
it belongs. Repeat after me: I shall not use overrides.

Cheers,
   - Andreas

On 7/17/09 6:34 PM, "Bert Freudenberg" <[hidden email]> wrote:

> No, you need to upload your new MorphicExtras package too, since you
> moved the method from Nebraska to this package.
>
Yes, Andreas points this.
I fix ASAP

Edgar

Andreas Raab wrote:
> Overrides. Evil Overrides. I put in a version that puts wait back where
> it belongs. Repeat after me: I shall not use overrides.

Oh, and I am only just realizing how evil these overrides are. You can't
really put the method back into its original category - even after
loading the updated kernel package Semaphore>>wait is still in the
override category and will surely cause problems somewhere down the
road. Is there an "official" MC way of fixing this problem or will we
have to do this via a doit (postscript or something)?

Cheers,
   - Andreas

On 18.07.2009, at 00:19, Andreas Raab wrote:


I think you would have to move it to *scripting first (without the  
override) and then to kernel.

But actually the PackageInfo version seems to be buggy because it  
simply assumes that when an override exists, the original method  
belongs to the package in question. But in the #wait case, no such  
method exists in the method history, presumably because sources were  
condensed without the overrides fix.

- Bert -

Ken Causey wrote:
> I'm not sure of the behavior of the updates process.  Is it possible
> that if I have neither .14 or .15 that in fact it doesn't merge 14 and
> then 15 but simply 15?  Perhaps it is in fact irrelevant.

Since Monticello stores an entire snapshot you really only need to load
the latest version since it will contain all the code that should be in
this package.

Intermediate stages are only required when there are dependency between
package versions that cannot be skipped over and just all loaded
together; for example the closure bootstrap heavily depends on a set of
prerequiste packages loaded together before it goes on to the next set
of packages. Basically, every update.mcm says "you must have loaded this
set of package versions before it is safe to load the next round of stuff".

And at the end of the process, when all of the configurations that list
explicit versions have been processed, the updater simply updates all
versions of packages listed in the last configuration to the highest
version number in the repository.

 > P.S. One thing the new update stream does appear to lack compared to the
 > old update stream is the ability to easily update only up to a certain
 > update number.  Is there some way that could be implemented?  Clearly
 > the trunk is not the simplistic linear thing the old update stream was.

We can do that and it's certainly worth considering. All it would take
is to not do the last part of the above description, i.e., do not update
beyond what is listed in the last configuration.

The consequence of the approach would be that once you've pushed a
change and it works you need to do an additional step and update the
configuration to include that package. If people feel it would be safer
to work that way, it would require only a tiny modification of the
script, at the cost of requiring two steps before a change really
reaches everyone who updates.

Comments? Preferences? Opinions?

Cheers,
  - Andreas

On Fri, 2009-07-17 at 21:54 -0700, Andreas Raab wrote: I'm not certain if we are talking about the same thing here.  I'm
thinking of an analog to

Utilities class>>updateFromServerThroughUpdateNumber:

and this would be done from the user side as desired.

I think I still don't quite understand MC configurations because the
model in my mind was simply that the .mcm specified packages and not
specific versions and that when you updated it updated all listed
packages to the latest versions in the repository.  However I just
looked at the latest update-ar.4.mcm and it does indeed specify
versions.  So that confuses me why we don't have to modify the .mcm
every time a new version is published.

Perhaps a way to do what I want could involve specifying a local
override to specific entries in the the mcm to only update to a certain
version of a package or perhaps not even load a package at all.

What I'm thinking of is something that I would expect to only rarely be
used and I wouldn't want to increase the effort required for each update
to the trunk to support a rare action.

Ken

On Sat, 2009-07-18 at 01:32 +0200, Bert Freudenberg wrote: Andreas: Is this what you ultimately did for Kernel-ar.190?

Ken

Ken Causey wrote:
That's because the updater does what you describe, but only for the
*latest* update.mcm. The updater first loads all the specific versions
that are in the list of update.mcm. With the *latest* update.mcm it then
simply updates all packages to the latest version. For example:

updates.1.mcm:
   Kernel-aa.1.mcz
   Collections-bb.3.mcz

updates.2.mcm:
   Collections-aa-5.mcz
   Kernel-bb.7.mcz

updates.3.mcm
   Kernel-aa.15.mcz
   Collections-bb.7.mcz

First, the updater loads what is listed in updates.1.mcm
(Kernel-aa.1.mcz, Collections-bb.3.mcz), then it goes on to
updates.2.mcm (Collections-aa.5.mcz, Kernel-bb.7.mcz) then updates.3.mcm
(Kernel-aa.15.mcz, Collections-bb.7.mcz).

Once it has loaded all these versions it takes updates.3.mcm and checks
whether there are any new versions of Kernel or Collections. If there
are, it loads (in the order that is given in updates.3.mcm; Kernel
first, then Collections).

> Perhaps a way to do what I want could involve specifying a local
> override to specific entries in the the mcm to only update to a certain
> version of a package or perhaps not even load a package at all.

It would be easy to support updating through a particular update.mcm
only. It would be harder to update through a specific package version
automatically but one could update to an earlier update.mcm and load the
remaining packages manually.

Cheers,
   - Andreas

Ken Causey wrote:
No, I didn't. I was just trying to move the method back into Kernel but
I guess this will need to be done via a doit.

Cheers,
   - Andreas

On 18.07.2009, at 19:50, Andreas Raab <[hidden email]> wrote:

One idea would be to "pin" down a particular package version locally.  
Or simply have a list of packages that should be excluded from  
updating beyond the latest version explicitly given in an mcm.

- Bert -

Am 18.07.2009 um 06:54 schrieb Andreas Raab: One advantage of having to update the configuration for each change  
would be that the update number could be used as a build number.

I have another question regarding the new development process: It is  
possible for a core developer to remove a package version from the  
trunk when he finds out that it breaks the update, right?

Cheers,
Bernhard

Bernhard Pieber wrote:
> I have another question regarding the new development process: It is
> possible for a core developer to remove a package version from the trunk
> when he finds out that it breaks the update, right?

Yes. All it takes is increasing the package version number. "Highest
number wins" is the rule for incremental updates, so saving the same
version again with a higher package version number will do the trick
just fine. (you can't actually "delete" things from Squeaksource unless
you are the server administrator)

Cheers,
   - Andreas