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