Hi Chris,

On Thu, May 14, 2020 at 12:38:20AM -0500, Chris Muller wrote:
> Dave,
> 
> The normal response of any application with a boostrap failure is to
> exit.  And as long as you have supervise instructed to keep the server
> running, that's what it will do.  It's not a "death spiral".  :)
> 
> > > On Wed, May 13, 2020 at 10:24 AM David T. Lewis <lewis at mail.msen.com> wrote:
> > > >
> > > > OK, it should be back now, and hopefully the mail delivery will be working again.
> > > >
> > > > I don't know the details, but it looks like the startup script is looking for
> > > > a file called "patch.st" to load. Chris had previously told me to rename that
> > > > file to "patch.st.old", which I had done. But today I wanted to undo my
> > > > earlier changes, and I renamed patch.st.old to patch.st.
> > >
> > > "Undoing your changes" would also mean undoing the image, which I
> > > assume you had renamed to ".old"...?
> > >
> >
> > No. I renamed the Sept 9, 2019 image per your direction, and I have not changed that.
> 
> I was referring to the proper way to "undo your changes".  If the
> system doesn't come right up and it isn't obvious, just execute your
> backout plan to backout 100% and regroup.  Putting the system into
> some "third" state on-the-fly that is neither what you tested, nor
> what the system was beforehand, is a recipe for problems.
> 
> A new system with an old patch is an invalid state for Personal
> SqueakSource.  Removing that file is part of the normal deployment
> process.  I'm sorry if it was confusing, but the system worked exactly
> as designed by refusing to run an invalid configuration.  The message
> in the log was clear, and you knew instantly what to do once you saw
> it.
> 
> What needs fixing at this point is that image -- we need to be using
> one built fresh with your MCConfigurations enhancement, so we know
> what code our server is running, can maintain and collaborate on it
> and be able to make fresh instantiations of it.
>

I'm not sure where to go with this. The ss repository already contained
copies of a number of MonticelloConfigurations packages, so I assumed
that you were keeping them there. Thus, I put a copy of the updated
package MonticelloConfigurations-dtl.161 on the ss repository.

But looking that the configurations that you published for Personal
SqueakSource on SqueakMap, you are not referencing any of the copies
in the ss repository. If you're building on a Squeak 5.2 release
image, you would either need to add a reference to the new copy in
the ss repository, or you would have to backport it to the squeak52
repository (I don't know if that's a good thing to do).

Your patch (the one in the patch.st file) is a bit more complicated.
I added it to the head of the updates as SqueakSource-dtl.1128.
However, that version is incompatible with the Squeak 5.2 release
image due to some intermediate changes, so it cannot be used in the
source.squeak.org image.

I think this means that if you want a SqueakSource package that
contains your patch, and if you want to run it on a Squeak 5.2 image,
then you would need to branch the packages (i.e. make a package
with SqueakSource-cmm.1123 as the parent, and save it as
SqueakSource.squeak52-cmm.1124).

Alternatively, you could just reinstate the patch.sh file on the
server and update its time stamp.

I'm happy to restore the patch.st file if you think that's the right
thing to do, but the rest of this stuff is a bit beyond my patience
threshold.

Dave