Ben Goetter wrote:
> From: Jerome Peace <peace_the_dreamer at yahoo.com>
>>  Sorry, I've given this a lot of thought which didn't
>> fit into the post. This has to do with work flow.
>
> Seconded with a newbie's enthusiasm.
>
> I'm more than a little confused about the Mantis workflow.  As an
> example(*), consider http://bugs.squeak.org/view.php?id=3311, where an
> individual identifies some lossage in the existing Complex class, then
> proposes a replacement class addressing the identified problems.
>
> In every project that I've known before, this would have been accepted
> into some build, or else deferred, or else rejected outright.  (By
> whom?  By some cabal or benevolent dictator.  All those projects have
> had such.)  Instead, this fix has simply sat there, apparently without
> comment, for the last two years.
>
> So I don't really see how Mantis works(**).  Yes, there's a place to
> report problems.  But do fixes come out of it?  If as part of a
> project of mine I can address some open issues therein, will they ever
> reach the mainstream?  May I just step in and claim a bug on my own,
> filing a suggested fix for it?  Also, if as part of a project of mine
> I can factor out some baseline kernel improvements, should I bother
> proposing them in Mantis?  Or should I just dump those base-class
> amendments into my package and let client handle the merge
> themselves?  A lot of the latter takes place right now....
>
> I'm not asking that anything change to accommodate my expectations.  I
> just want to understand how to work here.
>
> Cheers,
> Ben
Dear Ben,

The current process is such that a bug report and fix which hangs around
on mantis may at some point be harvested by an enthusiastic release team
member. In some cases it will attract the attention of someone who is
into bug harvesting, they will check its ok and point out to the release
team that it is ready. It is all very informal and actual process is
entirely dependent upon whatever the release team wants to do.

===
There are some up and coming improvements to this process...

Installer - Mantis Integration
====================

When you want to use or test a fix on mantis, append a note which
includes a script. The script indicates which of the uploaded files is
relevant. The script needs to be delimited like so.... e.g

"fix begin"
Installer mantis bug: 1234 fix: 'UploadedFile.1.cs'.
"fix test"
Installer mantis bug: 1234 fix: 'UploadedTest.1.cs'.
"fix end"

Given that the above script is in the mantis report, the following code
will load the fix changesets.

Installer mantis fixBug: 1234. 
or
Installer mantis fixBug: '1234 Informal fix description'.

So if you use Installer scripts to build your working or deployment
images, mantis uploaded files may be loaded via this
method.                                              

Level Playing Field - Scripts
====================

The second part of this process is LevelPlayingField. If you want to
write a public script which loads MyPackage into any version of squeak,
you could put that script on http://installer.pbwiki.com/MyPackage, with
different versions of the script for different squeak image versions,
e.g. http://installer.pbwiki.com/MyPackage-Squeak3:10 . These scripts
are also installer scripts and so they can add the required bug fixes
before the main package code is loaded. In this case the delimeter is
<code st>... </code st>

<code st>
Installer mantis ensureFix: 1234.
Installer squeaksource project: 'MyPackage'; install: 'MyPackage'.
</code st>

Level Playing Field image maintenance.
============================

Level Playing Field has a slot to which minor fixes can be appended to
an image.
so...

http://installer.pbwiki.com/MinorFixes-Squeak3:10 is where you put fixes
which apply to Squeak3.10, However the process is to begin by putting
your fix in http:installer.pbwiki.com-Squeak3:80/MinorFixesUnstable to
start with, until folks have at least tried it out.

Then interested users can load the minor fixes via,

Installer install: 'MinorFixesUnstable'.
or
Installer install: 'LatestUnstable'.  (which includes MinorFixesUnstable).

So... testers can easily get all of the pending fixes into their image,
fixes which will be moved to MinorFixes if they are shown to be good.

The next release team can use  Latest as part of their process and the
benefit from fixes which have already been ratified by end users.

I hope this answers some of your questions. Feel free to join in and
contribute to MinorFixesUnstable , the password is, somewhat
predicabky,  'squeak'

best regards

Keith