The latest MC1.5 has got smaller finally! The package has been split into two.
Monticello.impl Monticello.test
LPF only loads the implementation.
Keith
On Sun, Jun 01, 2008 at 01:49:13PM +0100, Keith Hodges wrote:
The latest MC1.5 has got smaller finally! The package has been split into two.
Monticello.impl Monticello.test
I tried loading these into my image, and I am unable to do so. Starting with an image with Monticello-kph.481 and PackageInfo-kph.27, I tried loading PackageInfo-kph.35, Monticello.impl-kph.501, and Monticello.test-kph.2
First, I tried loading MC and PI normally. After I loaded one, but not the other, I got some error. I forget what
Next, I tried bootstrapping. I loaded the source.st from each. In the middle of the MC file-in, I got an error, due to some interaction between SystemChangeNotifier and MC
Next, I tried manually halting SystemChangeNotifier by changing the value of silenceLevel to 1 in the inspector. I filed-in both MC and PI, re-enabled SystemChangeNotifier, and loading the MC and PI packages. I then tried loading the MC.tests package, but that then made the MC.impl package have a star next to it. So I tried reloading again MC-kph.501, but then I got an error due to a missing extension method
So, I'm unsure how to proceed.
My system is 3.10 + whatever LPF was current a few days ago (when I started debugging the MC ivars bug)
Matthew Fulmer wrote:
On Sun, Jun 01, 2008 at 01:49:13PM +0100, Keith Hodges wrote:
The latest MC1.5 has got smaller finally! The package has been split into two.
Monticello.impl Monticello.test
Squeaksource was down so I was unable to upload the final working implementations.
LPF Tested with Squeak 3.7 == Added SystemVersion-#majorMinorVersion to Kernel-Extensions to enable SqueakMap to be removed. Installer needs it and if you remove SqueakMap from 3.10 it dissappears.
Added the same to Monticello Backport.9.cs because 3.7 has the same issue when upgrading SqueakMap to 2.2
Moved the PackagesOrganizer from PackageInfo-Base to PackageInfo-Organizer to a separate package so that it can be a candidate for tidying/removal.
Added the following package types to package PackageInfo-Other
PackageInfoVW - *.vw PackageInfoDolphin - *.dolphin PackageInfoGS - *.gs
These packages ignore categories '*-Squeak', classes which return #isSqueakOnlyClass. They also ignore methods marked with pragma <excludeFromVW> etc.
Keith
Hello All,
There has been a fair bit of progress towards our Sake/Tasks's version of ReleaseBuilder. Although LPF uses external scripts to get going, once the basic tools are loaded we start to implement the rest of the release building process using tasks.
To have a look load the following into 3.10
Installer upgrade. Installer install: 'LevelPlayingField'. Installer install: 'Packages'. Installer install: 'Tasks'.
If you are feeling really brave try
TaskRelease next taskGenerateTestCandidate run.
We have a bug fix task which downloads and records the complete mantis report for each bug fix loaded. The result will be a that we automatically document all fixes that have been applied for this release.
best regards
Keith.
========
Here is an example task which calls in a bug fix:
TasksReleaseAfterSqueak310-#taskCleanDeprecated
^ self define: [ :task |
task dependsOn: { '6866 Refs Stop CurrentProjectRefactoring Removal'. }.
task action: [ Preferences noviceModeSettingChanged. "remove any old morphic key bindings" Installer mc unload: '39Deprecated'. ] ].
====================== the documentation looks like this as generated form mantis =======================
m6866RefsStopCurrentProjectRefactoringRemoval
Installer mantis bug:6866 fix:'RemoveCurrentProjectRefactoring.2.cs'.
"""""" Bug ID: 0006866 Category: [Squeak] System Severity: trivial Reproducibility: always Date Submitted: 01-21-08 17:32 Date Updated: 01-21-08 21:47 Reporter: Keith_Hodges View Status: public Handler: Priority: normal Resolution: open Status: new Product Version: 3.10 Summary: 0006866: References prevent removal of CurrentProjectRefactoring Description: Although marked as 39Deprecated some references linger Additional Information: Notes: (0011691 - 95 - 139 - 139 - 139 - 139 - 139) Keith_Hodges 01-21-08 17:33 edited on: 01-21-08 21:47 "fix begin" Installer mantis bug:6866 fix:'RemoveCurrentProjectRefactoring.2.cs'. "fix end"
Files: #('RemoveCurrentProjectRefactoring.1.cs' 'RemoveCurrentProjectRefactoring.2.cs')
Keith Hodges wrote:
Hello All,
There has been a fair bit of progress towards our Sake/Tasks's version of ReleaseBuilder.
And since some still cant see the point of doing it this way. I thought I would try a small explanation.
The plan is to change the development life cycle
From...
One person integrates a couple of small fixes -> generates an update - > publishes an image -> observers feedback (by which time the integrator has moved forward 5 steps) -> go around again -> (in case of a problem the integrator has to go back 5 steps to undo a mistake and then go around again).
From the fix developer point of view, if the fix doesnt work correctly they then have to produce a fix for the fix. The resultant "fix" is very specific, and cant be used elsewhere.
To...
A. Produce a Test Candidate image from current release + "Tasks", submit for test and feedback, improve/add/remove tasks, and build again.
Advantage 1: Tasks can be tested on old images, minimal images, full images, production in-use images and the current release. So the release work can be used in a pick and mix fashion by those who want to adopt it into other places. And each task can be more broadly tested (automated one hopes)
[All of the current tasks have been adopted into my main deployed image]
Advantage 2: Task developers, particularly those wanting to do a major refactoring are not working with a moving target." The update stream-only approach is a moving target.
Advantage 3: Newer ideas such as picking updates from several parallel update streams (i.e. DS) can be adopted into this framework.
Advantage 4: A lot of work can be accomplished in parallel and integrated.
Advantage 5: Tasks which do not make it into the release are not wasted, but can be used by those who want to use them, or deferred for later release cycle.
Advantage 6: A framework is established for future releases, enabling future "out of scope items" to be road-mapped. This means we can do some actual planning.
Advantage 7: Radical innovations can be included/removed very easily if they prove to cause a problem. But more importantly radical innovations are more likely with this model.
Advantage 8: Tasks which are developed on a minimal kernel image, can be tested on full-images. There is no need to wait until someone eventually takes the final release, loads all of their packages and THEN finds that it doesnt work.
Advantage 9: The overall control of the release progress is not constrained by one person. Tasks can be developed independently. The final vote on what the release contains can be offered to the community (if you dare).
B. Generate a Release candidate as a "simple" incremental change from the Current release
Automate the generation of an update from the current release to the next release given that the desired result is known in advance.
cheers
Keith
release@lists.squeakfoundation.org