Contributions
A) Small fixes ==========
1. Bugs are reported, discussed and fixes proposed on mantis. 2. When a fix is ready for harvesting a small installer script is appended as a note to the bug report. This script indicates exactly which files are required in order to fix this issue.
example script:
"fix begin" Installer mantis bug: 1234 fix: 'SomeFile.1.cs.gz'. "(.gz support is fixed)" "fix end"
3. Bugs will be nominated by those providing the fix for inclusion in the unstable build. We are still working out the details as to how this will be carried out. But it will be possible within Mantis.
3b. The build process tasks will need to be informed of any explicit dependencies between fixes if there are any. As long as it knows about them it will honour them.
4. The Unstable build will be automatically built (and tested) on a periodic basis.
The fixes are loaded into changesets with the bug fix number prepended to the changeset name. Also the full mantis report is copied into the image for documentation as to what has changed.
5. All packages effected by the most recently added fixes are written to Monticello, in such a way as the history for any one Monticello package makes it look like that package was incrementally fixed. In reality the build process starts from scratch every time.
By doing it this way we successfully combine the sensible way of fixing via changesets with the desired way of managing code in packages.
Keith
Keith Hodges wrote:
- Bugs will be nominated by those providing the fix for inclusion in
the unstable build. We are still working out the details as to how this will be carried out. But it will be possible within Mantis.
How about something like (with comma separator):
"fix begin: Squeak 3.10.2, Squeak 3.11 alpha" Installer mantis bug: 1234 fix: 'SomeFile.1.cs.gz'. "fix end"
Gives the option to note that this fix may be applicable to more than one version and gives the option to list alternatives like in:
"fix begin: Squeak 3.8" Installer mantis bug: 1234 fix: 'Fix-For3.8.cs.gz'. "fix end"
"fix begin: Squeak 3.10" Installer mantis bug: 1234 fix: 'Fix-For3.10.cs.gz'. "fix end"
3b. The build process tasks will need to be informed of any explicit dependencies between fixes if there are any. As long as it knows about them it will honour them.
If there are explicit dependencies, the script should list it:
"fix begin" Installer mantis bug: 1233 fix: 'Whatever.cs.gz'. "must be loaded first" Installer mantis bug: 1234 fix: 'SomeFile.1.cs.gz'. "fix end"
- All packages effected by the most recently added fixes are written to
Monticello, in such a way as the history for any one Monticello package makes it look like that package was incrementally fixed. In reality the build process starts from scratch every time.
That sounds good. One important thing to do here is to always list all the affected packages in the MC comment. Otherwise it's *very* hard to figure out what packages any particular fix affected if it's more than one.
By doing it this way we successfully combine the sensible way of fixing via changesets with the desired way of managing code in packages.
It's a sensible way of doing it. Two issues I'd like to bring up:
* As a step in the process, should we also convert the fixes to updates and locate them permanently at Squeak.org? Tracking incremental changes in MC is a pain and having a set of updates to look at could prove very valuable in the long term.
* Should the creation of the MC package updates be deferred up until (or briefly before) an impending release? The reasoning being that as long as this stuff is pulled from Mantis, one can update it and fix issues that are found in the process. Creating a new chain of MC packages every time something is changed in the middle would be a major hazzle for everyone involved.
If you need help with any of the above, let me know.
Cheers, - Andreas
Andreas Raab wrote:
Keith Hodges wrote:
- Bugs will be nominated by those providing the fix for inclusion in
the unstable build. We are still working out the details as to how this will be carried out. But it will be possible within Mantis.
How about something like (with comma separator):
I hadn't thought of that since I am/was trying to drive this from mantis' csv export. btw: Installer supports searching of that export.
m := Installer mantis (m select: [ :ea | ea category = 'Collections' ]) explore
"fix begin: Squeak 3.10.2, Squeak 3.11 alpha" Installer mantis bug: 1234 fix: 'SomeFile.1.cs.gz'. "fix end" Gives the option to note that this fix may be applicable to more than one version and gives the option to list alternatives like.
worth a thought.
3b. The build process tasks will need to be informed of any explicit dependencies between fixes if there are any. As long as it knows about them it will honour them.
If there are explicit dependencies, the script should list it:
The normal way of doing this is
"fix begin" Installer mantis ensureFix: 2345. Installer mantis bug: 1234 fix: 'SomeFile.1.cs.gz'. "fix end"
- All packages effected by the most recently added fixes are written to
Monticello, in such a way as the history for any one Monticello package makes it look like that package was incrementally fixed. In reality the build process starts from scratch every time.
That sounds good. One important thing to do here is to always list all the affected packages in the MC comment. Otherwise it's *very* hard to figure out what packages any particular fix affected if it's more than one.
ok
By doing it this way we successfully combine the sensible way of fixing via changesets with the desired way of managing code in packages.
It's a sensible way of doing it. Two issues I'd like to bring up:
- As a step in the process, should we also convert the fixes to
updates and locate them permanently at Squeak.org?
I was planning to work out the update story after we have a release candidate.
Tracking incremental changes in MC is a pain and having a set of updates to look at could prove very valuable in the long term.
- Should the creation of the MC package updates be deferred up until
(or briefly before) an impending release?
we can do both, in different repositories. One for work in progress (311rc) and one for final (squeakfoundation/311) ?.
The reasoning being that as long as this stuff is pulled from Mantis, one can update it and fix issues that are found in the process. Creating a new chain of MC packages every time something is changed in the middle would be a major hazzle for everyone involved.
If a mantis fix is changed in the middle, this would show up at the end in the 311rc repo.
If you need help with any of the above, let me know.
thanks for the offer,
A build of 3.10.2bc is now available on ftp.squeak.org/3.11/3.10.2bc
Keith
Stéphane Rollandin wrote:
A build of 3.10.2bc is now available on ftp.squeak.org/3.11/3.10.2bc
hello,
it seems that trying to open the SqueakMap Catalog in that image (located in an empty directory) raises an error.
Stef
Thanks for the feedback. We run cleanUpAll at the end of the build and I thought that our implementation of SMSqueakMap freeSomeSpace was non destructive.
I will add the following, to the build script.
Installer squeakmap update.
Keith
Keith Hodges wrote:
thanks for the offer,
A build of 3.10.2bc is now available on ftp.squeak.org/3.11/3.10.2bc
Keith
For a status view of the fixes included in this image in mantis
- make a filter which filters on - fixed in "3.10.2bc"
In this view I am using status colours as follows.
"Assigned" - pending inclusion in this release "Acknowledged" - being tested in recent builds "Confirmed" - is present in recent builds. "Resolved" - has been released in a final product.
regards
Keith
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Keith Hodges -
Stéphane Rollandin