>>>> - Inform us all when we stop using BFAV/mailinglist and move over to
>>>> Mantis.
>>>
>>> I think I should make it clear that using Mantis for BugTracking does
>>> not  necesarily
>>> mean that we will stop using BFAV for tracking and reviewing [ENH].
>>
>> True, but... well. I think we should - in the end - have *one* place 
>> to
>> look in, not multiple.
>> But sure, for a while we could use both in parallell.
>
> For now, I agree with the plan to have Mantis handle bug tracking, and 
> BFAV handle fix/enhancement tracking and approval.  There is only very 
> minimal support in BFAV for the bug tracking side, it was only added 
> recently... mostly the BFAV was set up to handle the submitted fixes & 
> enhancements.
>
> I was a bit cautious at first about the idea of introducing an 
> external bug tracker.  But there are some big advantages, namely 
> easy/quick access via a web browser, and better bug handling 
> functionality such as categorizing bugs by severity, category (section 
> of Squeak), etc.
>
> The main problem with having the two separate systems (one for 
> bugtracking, the other for fix/enh tracking) will be "connecting" the 
> two systems so that a bug in Mantis is associated with a fix/enh in 
> BFAV... e.g. so then when the fix/enh is approved/closed in BFAV, the 
> appropriate bug is closed in Mantis.

having a seaside application could be also a solution but we would have 
to write it.

Stef

> For now we will have to handle this by hand, which is OK while we are 
> still figuring out how best to use mantis.  But there may be a better 
> way to associate items between the two systems.
>
> Or, one eventual possibility is that the mantis DB also handles 
> fixes/enhs, as Goran suggested.  After playing with Mantis a bit, I 
> see that you can upload files, so fix/enh changesets could be attached 
> to bug reports.
>
> One thing I like about BFAV is that with the UI written in Squeak, you 
> can do things directly with the attached changesets such as "browse 
> code" or installing the changeset, or having my own tool (the Update 
> Incorporation Tool) operate on the changeset.  This advantage is 
> missing if you use Mantis in an external web browser.  However, if you 
> could use Mantis from within Squeak via the Scamper web browser, maybe 
> we could get roughly the same advantages.  Mantis doesn't use 
> JavaScript or frames or any other fancy crap^H^H^H^Hstuff, so that 
> might work.  Unfortunately Scamper is primitive to the point that it 
> doesn't really even support html tables that well, so that would need 
> to be fixed before this would really work well.  But if it did, we 
> could port parts of the BFAV UI such as the changeset operation menu 
> to work with Scamper/Mantis.
>
> Another whole issue is the concept of assigning bugs to people... I 
> assume Mantis supports this.  This could work right now for bugs 
> related to well-defined packages like SqueakMap, Monticello, 
> Balloon3D, etc., but right now it probably won't work for the rest of 
> the image, until we divide up responsibility of the image with the ol' 
> TNFR project.
>
> Anyway, this is just brainstorming.  For now let's just try handling 
> bug reports in Mantis and see how it goes.
>
>>> Testing/viewing changesets in BFAV is quite nice. But for Bugs, it 
>>> does
>>> nothing.
>>
>> Yes... Anyway, it would be nice to hear the BFAVers say something 
>> about
>> the future options.
>> For example, one variant could be to adjust BFAV so that it turns 
>> into a
>> "browser of Mantis" integrated into Squeak.
>
> Yep, that's another possibility.  I'd be happy to hear thoughts from 
> the BFAV guys too.  I know that Ken has talked about getting rid of 
> the email-based backend for the BFAV server, so perhaps Mantis would 
> be a reasonable backend.  Or not. :)
>
> - Doug
>
>