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