On Thu, May 22, 2014 at 1:37 AM, p...@highoctane.be <p...@highoctane.be>wrote:
> On Thu, May 22, 2014 at 1:18 AM, Eliot Miranda <eliot.mira...@gmail.com>wrote: > >> Hi All, >> >> >> On Wed, May 21, 2014 at 3:11 AM, stepharo <steph...@free.fr> wrote: >> >>> We would love to have a real update but I'm sure that you realize that >>> something we >>> are modifying the system that modify the methods modifying the system. >>> >> >> but we've been doing that for years. It used to be tricky using change >> sets, but Monticello's update scheme means it is very simple. >> >> >>> >>> So we should probably remove the software update button. >>> Now if somebody wants to work on an infrastructure supporting real >>> atomic load. >>> >> >> I don't think one needs atomic load to do this. It is very nice to have >> but Monticello's update scheme is sufficient. >> >> >>> Stef >>> PS: the last time I updated my iPhone it blocked and I had to fully >>> reinstall everything. >>> And once when I updated my mac my mouse got blocked forever on the left >>> top corner. >>> >>> But I can't remember the last time an update for Squeak failed and the >> updates are of the cool kind you mention. Personally I think having an >> update system is a *really important* facility in a development >> environment. It means I can keep my personal working environment >> up-to-date. That means I'm more likely to be able to contribute my own >> improvements to the system. >> >> I worked for a long time with VisualWorks which has a closed development >> cycle, and doesn't support anything like update. Keeping up to date was >> always slightly tedious (one had to do things like export one's own stuff >> and import it into the latest image, etc). Since I've been using Squeak >> I've understood how superior the Monticello scheme is. So I would urge you >> to /not/ remove the update button, and instead educate people in the >> process so that potentially dangerous changes are done properly (by >> defining baselines, a.k.a. updates in Monticello) and hence preserve the >> valuable ability to keep one's own image up-to-date. >> > > Mmh, it depends on how one considers images I guess. If the project can be > loaded based on a fresh image an packages (and configurations etc), images > are throwaway things. > Do I really have to defend image usage? Would you rebuild your laptop every night throwing away all your state? The synergy between the system's tools and its image is clear. Because the system operates on itself and provides persistence there is more ability and incentive to improve it. > > Using that approach (with the CI), one can recreate images easily. Okay, > it may mean a couple of minutes to rebuild but there are weird behaviors > when one messes with an image too much during development (as Ron commented > with change sets). > > Also, when does one updates? Updates on a fresh Pharo30 interest me. But > not on my dev image as there are a ton of packages loaded, some slices > packed on top to deal with some extra stuff. No wonder that updates on top > of that aren,'t going to fly. > Really? I regularly update my work image and it works well and I've lots loaded above it. If things break then fix them. Don't throw away value just because there are problems. That;s a race for the bottom that I see all too often in this community. It's the same refrain as "we should try to be as similar to the rest of the world as possible" and that leads to being the same as the rest of the world, which results in being redundant. > And Monticello is indeed super cool. Not always that cool with filtree:// > based repos but that is maybe because I do not grasp it all properly right > now (facing trouble with the metadata style files on merge with Git - > yes,filetree here, not gitfiletree - looking scary). > > > Phil > > >> >> -- >> best, >> Eliot >> > > -- best, Eliot
