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