[squeak-dev] 3.11 Process A) Small Fixes

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:
> 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.

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"

> 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.

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:
>> 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.
> 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"
>> 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.
> 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

> 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

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